From bradbell at seanet.com Fri May 2 03:17:48 2008 From: bradbell at seanet.com (Brad Bell) Date: Thu, 01 May 2008 20:17:48 -0700 Subject: [Fedora-packaging] Copyrighted specfiles. In-Reply-To: <20080430160028.E656D8E016F@hormel.redhat.com> References: <20080430160028.E656D8E016F@hormel.redhat.com> Message-ID: <481A87DC.9090006@seanet.com> Are specfiles covered by the Individual Contributor License Agreement (CLA) ? http://fedoraproject.org/wiki/Legal/Licenses/CLA > > Message: 1 > Date: 29 Apr 2008 22:42:46 -0500 > From: Jason L Tibbitts III > Subject: [Fedora-packaging] Copyrighted specfiles. > To: fedora-packaging at redhat.com > Message-ID: > Content-Type: text/plain; charset=us-ascii > > I have a specfile that begins with: > > # Copyright 2006-2008 Double Precision, Inc. > # See COPYING for distribution information. > > It looks like the specfile is carried in the tarball and the > maintainer just copies it out for the Fedora package. But this means > that when you unpack the srpm, you get a spec that refers to a file > which does not exist. > > Is it too much to ask that if for some reason you're going to > copyright the specfile you at least indicate the license in the > specfile? > > - J< > > > > From tcallawa at redhat.com Fri May 2 03:21:42 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 01 May 2008 23:21:42 -0400 Subject: [Fedora-packaging] Copyrighted specfiles. In-Reply-To: <481A87DC.9090006@seanet.com> References: <20080430160028.E656D8E016F@hormel.redhat.com> <481A87DC.9090006@seanet.com> Message-ID: <1209698502.20913.151.camel@localhost.localdomain> On Thu, 2008-05-01 at 20:17 -0700, Brad Bell wrote: > Are specfiles covered by the Individual Contributor License Agreement > (CLA) ? > http://fedoraproject.org/wiki/Legal/Licenses/CLA Yes, but only if they have no previous license. It does not replace the existing Copyright or licensing for the specfile. ~spot From tgl at redhat.com Mon May 5 16:40:53 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 05 May 2008 12:40:53 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? Message-ID: <445.1210005653@sss.pgh.pa.us> Is there, or should there be, any Fedora packaging policy about the following question? (I see nothing in the Guidelines at the moment.) Given a single SRPM generating multiple sub-RPMs, some of which depend on each other, how hard should the maintainer try to ensure that matching versions of the sub-RPMs are installed? Possible answers include: 1. Do nothing, rely on automatically generated requires (eg, the major version of a shared library's soname). Maximum flexibility, maximum possibility of allowing installations that don't actually work. 2. Put in cross-package requires of the form Requires: %{name}-libs = %{version} ie, constrain to "same upstream version" 3. Put in cross-package requires of the form Requires: %{name}-libs = %{version}-%{release} ie, constrain to "exact same build" Currently, I have some packages that do #2 and some that do #3, and I have an open bug suggesting that #3 is the way to go because it ensures yum will update all installed subpackages together: https://bugzilla.redhat.com/show_bug.cgi?id=444271 However this idea was questioned on an upstream mailing list on the grounds that users shouldn't be forced to update all subpackages together. I've got mixed feelings about it myself. I see the point about not constraining users unnecessarily, but there is no way that anyone is ever going to have done any testing on mix-and-match installations --- certainly I haven't got time to. (As an example of possible problems, different %{release} builds might have used different configure options, leading to builds that really are incompatible.) I think I'd rather ship RPMs that try to enforce that only tested combinations are installed. There's always --nodeps for those who think they're smarter than me... So, first, has anyone got an opinion about this, and second, should a policy recommendation be enshrined? regards, tom lane From j.w.r.degoede at hhs.nl Mon May 5 16:44:37 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 18:44:37 +0200 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <445.1210005653@sss.pgh.pa.us> References: <445.1210005653@sss.pgh.pa.us> Message-ID: <481F3975.10402@hhs.nl> Tom Lane wrote: > Is there, or should there be, any Fedora packaging policy about the > following question? (I see nothing in the Guidelines at the moment.) > > Given a single SRPM generating multiple sub-RPMs, some of which depend > on each other, how hard should the maintainer try to ensure that > matching versions of the sub-RPMs are installed? Possible answers > include: > > 1. Do nothing, rely on automatically generated requires (eg, the major > version of a shared library's soname). Maximum flexibility, maximum > possibility of allowing installations that don't actually work. > > 2. Put in cross-package requires of the form > Requires: %{name}-libs = %{version} > ie, constrain to "same upstream version" > > 3. Put in cross-package requires of the form > Requires: %{name}-libs = %{version}-%{release} > ie, constrain to "exact same build" > 3. definitely is the way to go, we currently already mandate this for -devel subpackages, which we need to generalize I think, we should mandate that: a. -devel subpackages require the main or a -libs subpackage b. that any inter srpm deps (including those from -devel on main / -libs) should be fully versioned Regards, Hans From nicolas.mailhot at laposte.net Mon May 5 19:13:27 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 May 2008 21:13:27 +0200 (CEST) Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <445.1210005653@sss.pgh.pa.us> References: <445.1210005653@sss.pgh.pa.us> Message-ID: <15294.192.54.193.57.1210014807.squirrel@rousalka.dyndns.org> Le Lun 5 mai 2008 18:40, Tom Lane a ?crit : > Given a single SRPM generating multiple sub-RPMs, some of which depend > on each other, how hard should the maintainer try to ensure that > matching versions of the sub-RPMs are installed? If you fear that mismatched subpackages may not work well together, I'd have them all conflict with versions < exact same build. What you're trying to describe is a conflict. Any sane repository will always have subpackages at the same build level, and not self-conflict (that's the main reason we ask people to avoid conflicts today; it wouldn't apply in your case). -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Mon May 5 19:35:10 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 21:35:10 +0200 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <15294.192.54.193.57.1210014807.squirrel@rousalka.dyndns.org> References: <445.1210005653@sss.pgh.pa.us> <15294.192.54.193.57.1210014807.squirrel@rousalka.dyndns.org> Message-ID: <481F616E.3040303@hhs.nl> Nicolas Mailhot wrote: > Le Lun 5 mai 2008 18:40, Tom Lane a ?crit : > >> Given a single SRPM generating multiple sub-RPMs, some of which depend >> on each other, how hard should the maintainer try to ensure that >> matching versions of the sub-RPMs are installed? > > If you fear that mismatched subpackages may not work well together, > I'd have them all conflict with versions < exact same build. What > you're trying to describe is a conflict. Any sane repository will > always have subpackages at the same build level, and not self-conflict > (that's the main reason we ask people to avoid conflicts today; it > wouldn't apply in your case). > Ugh, no no no, thats just ugly for no good reason, just add a Requires to the full version of the base package, or the sub-package that the sub-package needs. Regards, Hans From nicolas.mailhot at laposte.net Mon May 5 20:11:19 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 May 2008 22:11:19 +0200 (CEST) Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <481F616E.3040303@hhs.nl> References: <445.1210005653@sss.pgh.pa.us> <15294.192.54.193.57.1210014807.squirrel@rousalka.dyndns.org> <481F616E.3040303@hhs.nl> Message-ID: <22644.192.54.193.57.1210018279.squirrel@rousalka.dyndns.org> Le Lun 5 mai 2008 21:35, Hans de Goede a ?crit : > Nicolas Mailhot wrote: >> Le Lun 5 mai 2008 18:40, Tom Lane a ?crit : >> >>> Given a single SRPM generating multiple sub-RPMs, some of which >>> depend >>> on each other, how hard should the maintainer try to ensure that >>> matching versions of the sub-RPMs are installed? >> >> If you fear that mismatched subpackages may not work well together, >> I'd have them all conflict with versions < exact same build. What >> you're trying to describe is a conflict. Any sane repository will >> always have subpackages at the same build level, and not >> self-conflict >> (that's the main reason we ask people to avoid conflicts today; it >> wouldn't apply in your case). >> > > Ugh, no no no, thats just ugly for no good reason, just add a Requires > to the > full version of the base package, or the sub-package that the > sub-package needs. That only works if you have a nice subpackage hierarchy. Not all packages are like that -- Nicolas Mailhot From caillon at redhat.com Mon May 5 21:00:12 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 05 May 2008 17:00:12 -0400 Subject: [Fedora-packaging] desktop file validation In-Reply-To: <4808C763.8010508@redhat.com> References: <4808C763.8010508@redhat.com> Message-ID: <481F755C.5070004@redhat.com> On 04/18/2008 12:08 PM, Christopher Aillon wrote: > I got recently called out for using desktop-file-validate instead of > desktop-file-install when the upstream .desktop file is correct, doesn't > need to be changed, and make install already places it in the correct > location. > > Since the purpose of this guideline is to validate, I propose to amend > the section of the packaging guidelines on desktop-file-install usage[1] > as follows: > > * Rename the sub-heading from "desktop-file-install" to ".desktop file > installation and validation" > > * Change the first sentence to: > > << > It is not simply enough to just include the .desktop file in the > package, one MUST run desktop-file-install OR desktop-file-validate in > %install (and have BuildRequires: desktop-file-utils), to help ensure > .desktop file safety and spec-compliance. desktop-file-install MUST be > used if the package does not install the file or there are changes > desired to the .desktop file (such as add/removing categories, etc). > desktop-file-validate MAY be used instead if the .desktop file's > content/location does not need modification. Here are some examples of > usage: > >> > > * Add the following example: > > << > desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop > >> > > > > Thoughts? > Any word on this? Can this be voted on? From j.w.r.degoede at hhs.nl Mon May 5 21:02:20 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 05 May 2008 23:02:20 +0200 Subject: [Fedora-packaging] desktop file validation In-Reply-To: <481F755C.5070004@redhat.com> References: <4808C763.8010508@redhat.com> <481F755C.5070004@redhat.com> Message-ID: <481F75DC.305@hhs.nl> Christopher Aillon wrote: > On 04/18/2008 12:08 PM, Christopher Aillon wrote: >> I got recently called out for using desktop-file-validate instead of >> desktop-file-install when the upstream .desktop file is correct, >> doesn't need to be changed, and make install already places it in the >> correct location. >> >> Since the purpose of this guideline is to validate, I propose to amend >> the section of the packaging guidelines on desktop-file-install >> usage[1] as follows: >> >> * Rename the sub-heading from "desktop-file-install" to ".desktop file >> installation and validation" >> >> * Change the first sentence to: >> >> << >> It is not simply enough to just include the .desktop file in the >> package, one MUST run desktop-file-install OR desktop-file-validate in >> %install (and have BuildRequires: desktop-file-utils), to help ensure >> .desktop file safety and spec-compliance. desktop-file-install MUST be >> used if the package does not install the file or there are changes >> desired to the .desktop file (such as add/removing categories, etc). >> desktop-file-validate MAY be used instead if the .desktop file's >> content/location does not need modification. Here are some examples >> of usage: >> >> >> >> * Add the following example: >> >> << >> desktop-file-validate %{buildroot}/%{_datadir}/applications/foo.desktop >> >> >> >> >> >> Thoughts? >> > > Any word on this? Can this be voted on? > Looks good (and reasonable) to me. Regards, Hans From a.badger at gmail.com Mon May 5 21:07:03 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 May 2008 14:07:03 -0700 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <481F3975.10402@hhs.nl> References: <445.1210005653@sss.pgh.pa.us> <481F3975.10402@hhs.nl> Message-ID: <481F76F7.5030803@gmail.com> Hans de Goede wrote: > Tom Lane wrote: >> Is there, or should there be, any Fedora packaging policy about the >> following question? (I see nothing in the Guidelines at the moment.) >> >> Given a single SRPM generating multiple sub-RPMs, some of which depend >> on each other, how hard should the maintainer try to ensure that >> matching versions of the sub-RPMs are installed? Possible answers >> include: >> >> 1. Do nothing, rely on automatically generated requires (eg, the major >> version of a shared library's soname). Maximum flexibility, maximum >> possibility of allowing installations that don't actually work. >> >> 2. Put in cross-package requires of the form >> Requires: %{name}-libs = %{version} >> ie, constrain to "same upstream version" >> >> 3. Put in cross-package requires of the form >> Requires: %{name}-libs = %{version}-%{release} >> ie, constrain to "exact same build" >> > > 3. definitely is the way to go, we currently already mandate this for > -devel > subpackages, which we need to generalize I think, we should mandate > that: > > a. -devel subpackages require the main or a -libs subpackage > b. that any inter srpm deps (including those from -devel on main / -libs) > should be fully versioned > s/inter/intra/ I think this is the way to go. -Toshio From tgl at redhat.com Mon May 5 23:40:20 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 05 May 2008 19:40:20 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <22644.192.54.193.57.1210018279.squirrel@rousalka.dyndns.org> References: <445.1210005653@sss.pgh.pa.us> <15294.192.54.193.57.1210014807.squirrel@rousalka.dyndns.org> <481F616E.3040303@hhs.nl> <22644.192.54.193.57.1210018279.squirrel@rousalka.dyndns.org> Message-ID: <5029.1210030820@sss.pgh.pa.us> "Nicolas Mailhot" writes: > Le Lun 5 mai 2008 21:35, Hans de Goede a ??crit : >> Ugh, no no no, thats just ugly for no good reason, just add a Requires >> to the full version of the base package, or the sub-package that the >> sub-package needs. > That only works if you have a nice subpackage hierarchy. Not all > packages are like that Sure, but I don't think we should saddle every package with complexity that is only needed in a few special cases. My packages all have very simple subpackage structure, and AFAICS putting in Conflicts: would just be overkill. Another possible issue is whether a Conflicts-based solution is as friendly to the depsolver. I have no idea if it's true or not, but it seems at least possible that "get me this version" is faster to solve than "don't get me this version, but you'd better find something". regards, tom lane From rdieter at math.unl.edu Tue May 6 12:25:47 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 06 May 2008 07:25:47 -0500 Subject: [Fedora-packaging] Re: Policy question: how tight should cross-subpackage Requires be? References: <445.1210005653@sss.pgh.pa.us> <15294.192.54.193.57.1210014807.squirrel@rousalka.dyndns.org> <481F616E.3040303@hhs.nl> <22644.192.54.193.57.1210018279.squirrel@rousalka.dyndns.org> <5029.1210030820@sss.pgh.pa.us> Message-ID: Tom Lane wrote: > Another possible issue is whether a Conflicts-based solution is as > friendly to the depsolver. I have no idea if it's true or not In general, it is not, which is one reason why the current guidelines pretty much ban the explicit use of Conflicts (except for rare/exceptional cases). -- Rex From foster at in.tum.de Tue May 6 14:01:34 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Tue, 6 May 2008 15:01:34 +0100 Subject: [Fedora-packaging] Re: python packaging - icons/desktop files and /usr/bin accessibility In-Reply-To: <481F81FE.5020500@gmail.com> References: <481EFE72.1030105@iinet.net.au> <481F81FE.5020500@gmail.com> Message-ID: [ NB: I sent this to fedora-packaging as well as fedora-devel, and it's probably better to follow up there because this thread is shifting focus ... ] On Mon, May 5, 2008 at 10:54 PM, Toshio Kuratomi wrote: > I took a closer look at Ice and I think there's a few things that should > change. > > 1) AFAICS there's no reason for the python bindings to be part of the Ice > package. It comes in a separate tarball and appears to build on its own. I > can't find a mention of this in the review so I don't know if there's > something special about it that I'm missing. [1]_ Actually, upstream is very soon releasing a new version of Ice where all of the language bindings are in a single tarball, so I think I'll stick with the monolithic SRPM. > 2) The .pth file looks like it's being used to compensate for bad imports > and upstream packaging. > * There should be an __init__.py file in > %{_libdir}/pythonX.Y/site-packages/Ice > > * The following files have imports that need to be changed: > IceBox/__init__.py > Glacier2/__init__.py > IceGrid/__init__.py > IceStorm/__init__.py > IcePatch2/__init__.py > > change imports like:: > import IceBox_IceBox_ice > to this:: > from Ice import IceBox_IceBox_ice The problem is, those files are automatically generated using other parts of the Ice program (using slice2py, to be specific). There's a documented way that slice2py deals with packages and modules (http://zeroc.com/doc/Ice-3.2.1/manual/Python.23.15.html#75777) that I'm reluctant to touch. I could remove the "Ice.pth" file and require people to set PYTHONPATH, but unfortunately I don't think I can go changing the actual (generated) __init__.py files. :( > 3) Additionally, on x86_64, the python module is spread over two > directories: /usr/lib64/python2.5/site-packages/Ice and > /usr/lib/python2.5/site-packages/Ice. Python doesn't handle that very well. > All the files of a module should be in a single directory. Since this > module builds an ELF shared object (IcePy.so/IcePy.so.3.2.1) all files > should be installed into %{python_sitearch}/ (This is what lead to BZ > #392751). Okay, sure, that's easy to fix. So I should put *.py* into site_arch always, and put nothing into site_lib? The Python packaging guidelines aren't amazingly clear on this point to a non-Python programmer like me. :) MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From a.badger at gmail.com Tue May 6 15:04:36 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 06 May 2008 08:04:36 -0700 Subject: [Fedora-packaging] Re: python packaging - icons/desktop files and /usr/bin accessibility In-Reply-To: References: <481EFE72.1030105@iinet.net.au> <481F81FE.5020500@gmail.com> Message-ID: <48207384.4090801@gmail.com> Mary Ellen Foster wrote: > On Mon, May 5, 2008 at 10:54 PM, Toshio Kuratomi wrote: >> I took a closer look at Ice and I think there's a few things that should >> change. >> >> 1) AFAICS there's no reason for the python bindings to be part of the Ice >> package. It comes in a separate tarball and appears to build on its own. I >> can't find a mention of this in the review so I don't know if there's >> something special about it that I'm missing. [1]_ > > Actually, upstream is very soon releasing a new version of Ice where > all of the language bindings are in a single tarball, so I think I'll > stick with the monolithic SRPM. > Okay. That's not something I'd have done but I'm not upstream :-/ Choosing to follow upstream on your part is sane. >> 2) The .pth file looks like it's being used to compensate for bad imports >> and upstream packaging. >> * There should be an __init__.py file in >> %{_libdir}/pythonX.Y/site-packages/Ice >> >> * The following files have imports that need to be changed: >> IceBox/__init__.py >> Glacier2/__init__.py >> IceGrid/__init__.py >> IceStorm/__init__.py >> IcePatch2/__init__.py >> >> change imports like:: >> import IceBox_IceBox_ice >> to this:: >> from Ice import IceBox_IceBox_ice > > The problem is, those files are automatically generated using other > parts of the Ice program (using slice2py, to be specific). There's a > documented way that slice2py deals with packages and modules > (http://zeroc.com/doc/Ice-3.2.1/manual/Python.23.15.html#75777) that > I'm reluctant to touch. > > I could remove the "Ice.pth" file and require people to set > PYTHONPATH, but unfortunately I don't think I can go changing the > actual (generated) __init__.py files. :( > PYTHONPATH would be wrong for a module, you're correct. Let me look at slice2py to see if we can submit a patch upstream for that program to do things right. Reading the documentation makes it more apparent that using a .pth is wrong... If ice becomes popular there will be a lot of namespace pollution due to that. Their example of: module OS { [...] } coupled with a .pth file quickly makes you realize that it would be very easy for an ice generated module to conflict with other python modules if they are not given their own namespace. ie: without a .pth file, you'd have to do this:: import ice.os with the .pth file this can quickly happen:: import os Now, is that the ice os module or the python standard library os module? >> 3) Additionally, on x86_64, the python module is spread over two >> directories: /usr/lib64/python2.5/site-packages/Ice and >> /usr/lib/python2.5/site-packages/Ice. Python doesn't handle that very well. >> All the files of a module should be in a single directory. Since this >> module builds an ELF shared object (IcePy.so/IcePy.so.3.2.1) all files >> should be installed into %{python_sitearch}/ (This is what lead to BZ >> #392751). > > Okay, sure, that's easy to fix. So I should put *.py* into site_arch > always, and put nothing into site_lib? For ice or any other module that has a compiled object (.so) as part of the module, yes. Basically, you can create a module in %{pythonsite_arch}/MODULE *or* %{pythonsite_lib}/MODULE. Trying to create pieces of the module in both will just confuse the python interpreter. Most of the python modules that are bindings for C libraries (for instance, psycopg2 which provides bindings for the postgresql libs) end up in sitearch for that reason even if they have significant pieces written in pure python. Other packages (for instance yum combined with yum-metadata-parser) split the pure python and compiled portions into two separate modules. The pure python module can then reside in sitelib and import the compiled module from sitearch. > The Python packaging guidelines > aren't amazingly clear on this point to a non-Python programmer like > me. :) > These monolithic packages end up harder to maintain because of that... you need to have domain specific knowledge about all the languages and quirks involved rather than just one but if upstream's moving to a single tarball, then it's not an issue we can easily solve in distro packaging. If you would like to make this clearer, feel free to jot down some wording and tell me where it would make the most sense to appear in the Guidelines. Additions to clarify things are always welcome. -Toshio From ivazqueznet at gmail.com Wed May 7 02:31:25 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 06 May 2008 22:31:25 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <445.1210005653@sss.pgh.pa.us> References: <445.1210005653@sss.pgh.pa.us> Message-ID: <1210127485.28402.52.camel@ignacio.lan> On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote: > Given a single SRPM generating multiple sub-RPMs, some of which depend > on each other, how hard should the maintainer try to ensure that > matching versions of the sub-RPMs are installed? Possible answers > include: > > 1. Do nothing, rely on automatically generated requires (eg, the major > version of a shared library's soname). Maximum flexibility, maximum > possibility of allowing installations that don't actually work. Show me a package that would break if a different version library was used that has the same soname and I'll show you a developer that needs to learn how to properly use sonames. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Wed May 7 02:43:01 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 06 May 2008 22:43:01 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <1210127485.28402.52.camel@ignacio.lan> References: <445.1210005653@sss.pgh.pa.us> <1210127485.28402.52.camel@ignacio.lan> Message-ID: <1210128181.28402.53.camel@ignacio.lan> On Tue, 2008-05-06 at 22:31 -0400, Ignacio Vazquez-Abrams wrote: > Show me a package that would break if a different version library was > used that has the same soname and I'll show you a developer that needs > to learn how to properly use sonames. Different *newer*, of course. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tgl at redhat.com Wed May 7 03:01:16 2008 From: tgl at redhat.com (Tom Lane) Date: Tue, 06 May 2008 23:01:16 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <1210127485.28402.52.camel@ignacio.lan> References: <445.1210005653@sss.pgh.pa.us> <1210127485.28402.52.camel@ignacio.lan> Message-ID: <29141.1210129276@sss.pgh.pa.us> Ignacio Vazquez-Abrams writes: > On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote: >> 1. Do nothing, rely on automatically generated requires (eg, the major >> version of a shared library's soname). Maximum flexibility, maximum >> possibility of allowing installations that don't actually work. > Show me a package that would break if a different version library was > used that has the same soname and I'll show you a developer that needs > to learn how to properly use sonames. Hmm, you think a version digit or so is enough to encode everything there is to be known about a package? I'm using a fairly wide definition of "break" here, such as package A not having an optional capability that package B expects it to have --- in the context of the stuff I work with, a good example would be SSL support in a client library. A non-SSL-capable client could fail to interoperate with a server that was configured to demand SSL protection, or vice versa. And that would have nothing to do with whether the client library could successfully link with its calling application, which is the sum total of what the soname is expected to handle. The soname convention simply hasn't got the bandwidth to handle every possible combination of build options that a given upstream tarball might support. In places where it really matters, we have developed conventions for Requires: symbols that can convey fine detail, for instance BuildRequires: perl(ExtUtils::Embed) But I can't see going to that much trouble for intramural dependencies among the subpackages of a single SRPM. regards, tom lane From rc040203 at freenet.de Wed May 7 04:32:10 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 06:32:10 +0200 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <29141.1210129276@sss.pgh.pa.us> References: <445.1210005653@sss.pgh.pa.us> <1210127485.28402.52.camel@ignacio.lan> <29141.1210129276@sss.pgh.pa.us> Message-ID: <1210134730.26792.305.camel@beck.corsepiu.local> On Tue, 2008-05-06 at 23:01 -0400, Tom Lane wrote: > Ignacio Vazquez-Abrams writes: > > On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote: > >> 1. Do nothing, rely on automatically generated requires (eg, the major > >> version of a shared library's soname). Maximum flexibility, maximum > >> possibility of allowing installations that don't actually work. > > > Show me a package that would break if a different version library was > > used that has the same soname and I'll show you a developer that needs > > to learn how to properly use sonames. > > Hmm, you think a version digit or so is enough to encode everything > there is to be known about a package? Think of SONAMES in terms of APIs. Two packages providing a library with the same SONAME must be API-compatible and remain API-compatible throughout a distributions life-time. Read "info libtool" for one approach to it. More generally speaking, version-numbers will never be enough to "encode everything ... about a package". They are a minimum, "necessary requirement" and will need to be supported by further measures. Which, depends on your individual case. For compile time deps, "compile-time feature-checks" are an appropriate means, in other situations, you may use run-time checks, ... if all else fail, you will need to resort to "conventions". Ralf From tgl at redhat.com Wed May 7 04:46:54 2008 From: tgl at redhat.com (Tom Lane) Date: Wed, 07 May 2008 00:46:54 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <1210134730.26792.305.camel@beck.corsepiu.local> References: <445.1210005653@sss.pgh.pa.us> <1210127485.28402.52.camel@ignacio.lan> <29141.1210129276@sss.pgh.pa.us> <1210134730.26792.305.camel@beck.corsepiu.local> Message-ID: <311.1210135614@sss.pgh.pa.us> Ralf Corsepius writes: > On Tue, 2008-05-06 at 23:01 -0400, Tom Lane wrote: >> Hmm, you think a version digit or so is enough to encode everything >> there is to be known about a package? > Think of SONAMES in terms of APIs. Two packages providing a library with > the same SONAME must be API-compatible and remain API-compatible > throughout a distributions life-time. Actually, I think SONAME is supposed to promise ABI compatibility, which is not the same as API compatibility. But that's a marginal issue. The point I was trying to make is that a library can have a lot of behaviors that do not, and SHOULD NOT, involve breakage of its ABI contract; and yet can well impinge on its ability to play nice with other packages that are outside the scope of its ABI. regards, tom lane From rc040203 at freenet.de Wed May 7 04:58:23 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 May 2008 06:58:23 +0200 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <311.1210135614@sss.pgh.pa.us> References: <445.1210005653@sss.pgh.pa.us> <1210127485.28402.52.camel@ignacio.lan> <29141.1210129276@sss.pgh.pa.us> <1210134730.26792.305.camel@beck.corsepiu.local> <311.1210135614@sss.pgh.pa.us> Message-ID: <1210136303.26792.332.camel@beck.corsepiu.local> On Wed, 2008-05-07 at 00:46 -0400, Tom Lane wrote: > Ralf Corsepius writes: > > On Tue, 2008-05-06 at 23:01 -0400, Tom Lane wrote: > >> Hmm, you think a version digit or so is enough to encode everything > >> there is to be known about a package? > > > Think of SONAMES in terms of APIs. Two packages providing a library with > > the same SONAME must be API-compatible and remain API-compatible > > throughout a distributions life-time. > > Actually, I think SONAME is supposed to promise ABI compatibility, > which is not the same as API compatibility. Pedantically speaking, you are right. It's only that from a library implementor's point of view, the real ABI (Compiler, object format/ELF) must remain constant and unchanged, i.e. they use SONAMEs to version their APIs under the premise of a constant ABI. > But that's a marginal > issue. The point I was trying to make is that a library can have a lot > of behaviors that do not, and SHOULD NOT, involve breakage of its ABI > contract; and yet can well impinge on its ability to play nice with > other packages that are outside the scope of its ABI. Ralf From jonathan.underwood at gmail.com Wed May 7 23:30:14 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 8 May 2008 00:30:14 +0100 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <481F3975.10402@hhs.nl> References: <445.1210005653@sss.pgh.pa.us> <481F3975.10402@hhs.nl> Message-ID: <645d17210805071630n37e89726r94554810842b9ea@mail.gmail.com> 2008/5/5 Hans de Goede : > Tom Lane wrote: [snip] > > 3. Put in cross-package requires of the form > > Requires: %{name}-libs = %{version}-%{release} > > ie, constrain to "exact same build" > > > > > > 3. definitely is the way to go, we currently already mandate this for > -devel > subpackages, which we need to generalize I think, we should mandate that: > > a. -devel subpackages require the main or a -libs subpackage > b. that any inter srpm deps (including those from -devel on main / -libs) > should be fully versioned Assuming that 3. is indeed the way to go (and that seems right to me), shouldn't rpmbuild actually be fixed to enforce this? From tcallawa at redhat.com Thu May 8 01:28:09 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 07 May 2008 21:28:09 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <645d17210805071630n37e89726r94554810842b9ea@mail.gmail.com> References: <445.1210005653@sss.pgh.pa.us> <481F3975.10402@hhs.nl> <645d17210805071630n37e89726r94554810842b9ea@mail.gmail.com> Message-ID: <1210210089.15217.142.camel@localhost.localdomain> On Thu, 2008-05-08 at 00:30 +0100, Jonathan Underwood wrote: > Assuming that 3. is indeed the way to go (and that seems right to me), > shouldn't rpmbuild actually be fixed to enforce this? No, because 3 isn't always true, and rpm has no way of knowing what a -libs package means. ~spot From tgl at redhat.com Thu May 8 04:03:10 2008 From: tgl at redhat.com (Tom Lane) Date: Thu, 08 May 2008 00:03:10 -0400 Subject: [Fedora-packaging] Policy question: how tight should cross-subpackage Requires be? In-Reply-To: <1210210089.15217.142.camel@localhost.localdomain> References: <445.1210005653@sss.pgh.pa.us> <481F3975.10402@hhs.nl> <645d17210805071630n37e89726r94554810842b9ea@mail.gmail.com> <1210210089.15217.142.camel@localhost.localdomain> Message-ID: <25696.1210219390@sss.pgh.pa.us> "Tom \"spot\" Callaway" writes: > On Thu, 2008-05-08 at 00:30 +0100, Jonathan Underwood wrote: >> Assuming that 3. is indeed the way to go (and that seems right to me), >> shouldn't rpmbuild actually be fixed to enforce this? > No, because 3 isn't always true, and rpm has no way of knowing what a > -libs package means. I agree. This is very probably good as a standard policy recommendation, but it's a long way from there to a "no exceptions" policy. The bottom line as far as I can tell is that enforcing same-release match for subpackages of an RPM is a good idea when you don't want to think very hard about the compatibility implications of a mixed-release situation. If a package maintainer *is* willing to think hard, we should allow him to do that. regards, tom lane From orion at cora.nwra.com Fri May 9 15:31:17 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 09 May 2008 09:31:17 -0600 Subject: [Fedora-packaging] Updates to R packaging spec Message-ID: <48246E45.4040701@cora.nwra.com> Doing some new R packages, seems like the following changes should be make to the spec examples in http://fedoraproject.org/wiki/Packaging/R: Source0: http://cran.r-project.org/src/contrib/%{packname}_%{version}-%{packrel}.tar.gz URL: http://cran.r-project.org/web/packages/%{packname}/index.html BuildRequires: R-devel, tex(latex) (though only for F-9 and later) Also, the noarch spec requires R but the arch doesn't. This may be correct (arch probably depends on R libraries), but you might note it in the summary of differences section. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From dev at nigelj.com Mon May 12 22:45:37 2008 From: dev at nigelj.com (Nigel Jones) Date: Tue, 13 May 2008 10:45:37 +1200 Subject: [Fedora-packaging] SELinux Policy Message-ID: <4828C891.20300@nigelj.com> Hey guys, Can someone let me know what the current status of the SELinux policy is, podsleuth needs an extensive policy, but I don't want it in the upstream selinux-policy yet. I noticed http://fedoraproject.org/wiki/PackagingDrafts/SELinux and http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules but they seem quite old and out of date. Help is appreciated! - Nigel From mike at flyn.org Thu May 15 17:59:52 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 15 May 2008 13:59:52 -0400 Subject: [Fedora-packaging] Retrograde package version Message-ID: <20080515175952.GA7325@imp.flyn.org> I recently followed another distribution's lead and made some assumptions about the version numbering of a package I maintain, mt-daapd. I released a bugfix in the form of: mt-daapd-0.9-0.4.1696.fc8 mt-daapd-0.9-0.2.1696.fc9 mt-daapd-0.9-0.2.1696.el5 I had thought that the next release would be in the 0.9 series. Now, the bugfix is upstream and the author has released the next version of mt-daapd. Unfortunately, this version is 0.2.4.2, which is lower that the versions above. I'd like to supercede the packages above with this "lower" version number. What is the best way to handle this? I'd like to avoid using the 0.9 version, as the developer has not moved to this yet upstream. Mike From limb at jcomserv.net Thu May 15 18:02:20 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 15 May 2008 13:02:20 -0500 (CDT) Subject: [Fedora-packaging] Retrograde package version In-Reply-To: <20080515175952.GA7325@imp.flyn.org> References: <20080515175952.GA7325@imp.flyn.org> Message-ID: <27712.198.175.55.5.1210874540.squirrel@mail.jcomserv.net> > I recently followed another distribution's lead and made some assumptions > about the version numbering of a package I maintain, mt-daapd. > > I released a bugfix in the form of: > > mt-daapd-0.9-0.4.1696.fc8 > mt-daapd-0.9-0.2.1696.fc9 > mt-daapd-0.9-0.2.1696.el5 > > I had thought that the next release would be in the 0.9 series. > > Now, the bugfix is upstream and the author has released the next version > of mt-daapd. Unfortunately, this version is 0.2.4.2, which is lower that > the versions above. I'd like to supercede the packages above with this > "lower" version number. > > What is the best way to handle this? I'd like to avoid using the 0.9 > version, as the developer has not moved to this yet upstream. Epoch bump? > Mike > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- novus ordo absurdum From mike at flyn.org Thu May 15 22:37:31 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 15 May 2008 18:37:31 -0400 Subject: [Fedora-packaging] Retrograde package version In-Reply-To: <27712.198.175.55.5.1210874540.squirrel@mail.jcomserv.net> References: <20080515175952.GA7325@imp.flyn.org> <27712.198.175.55.5.1210874540.squirrel@mail.jcomserv.net> Message-ID: <20080515223731.GB9619@imp.flyn.org> >> I recently followed another distribution's lead and made some assumptions >> about the version numbering of a package I maintain, mt-daapd. >> >> I released a bugfix in the form of: >> >> mt-daapd-0.9-0.4.1696.fc8 >> mt-daapd-0.9-0.2.1696.fc9 >> mt-daapd-0.9-0.2.1696.el5 >> >> I had thought that the next release would be in the 0.9 series. >> >> Now, the bugfix is upstream and the author has released the next version >> of mt-daapd. Unfortunately, this version is 0.2.4.2, which is lower that >> the versions above. I'd like to supercede the packages above with this >> "lower" version number. >> >> What is the best way to handle this? I'd like to avoid using the 0.9 >> version, as the developer has not moved to this yet upstream. > Epoch bump? As far as I know, the epoch does not override the version for the update path. Mike From a.badger at gmail.com Thu May 15 22:50:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 15 May 2008 15:50:13 -0700 Subject: [Fedora-packaging] Retrograde package version In-Reply-To: <20080515223731.GB9619@imp.flyn.org> References: <20080515175952.GA7325@imp.flyn.org> <27712.198.175.55.5.1210874540.squirrel@mail.jcomserv.net> <20080515223731.GB9619@imp.flyn.org> Message-ID: <482CBE25.7060000@gmail.com> W. Michael Petullo wrote: > >> Epoch bump? > > As far as I know, the epoch does not override the version for the > update path. > That's actually what it's for. Epoch trumps version so that you can work around things like broken upstream numbering or cases like this. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From paul at city-fan.org Thu May 15 22:52:24 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 May 2008 23:52:24 +0100 Subject: [Fedora-packaging] Retrograde package version In-Reply-To: <20080515223731.GB9619@imp.flyn.org> References: <20080515175952.GA7325@imp.flyn.org> <27712.198.175.55.5.1210874540.squirrel@mail.jcomserv.net> <20080515223731.GB9619@imp.flyn.org> Message-ID: <20080515235224.37355d9d@metropolis.intra.city-fan.org> On Thu, 15 May 2008 18:37:31 -0400 "W. Michael Petullo" wrote: > >> I released a bugfix in the form of: > >> > >> mt-daapd-0.9-0.4.1696.fc8 > >> mt-daapd-0.9-0.2.1696.fc9 > >> mt-daapd-0.9-0.2.1696.el5 > >> > >> I had thought that the next release would be in the 0.9 series. > >> > >> Now, the bugfix is upstream and the author has released the next > >> version of mt-daapd. Unfortunately, this version is 0.2.4.2, which > >> is lower that the versions above. I'd like to supercede the > >> packages above with this "lower" version number. > >> > >> What is the best way to handle this? I'd like to avoid using the > >> 0.9 version, as the developer has not moved to this yet upstream. > > > Epoch bump? > > As far as I know, the epoch does not override the version for the > update path. Overriding the version is the entire raison d'?tre of epoch, isn't it? Paul. From mike at flyn.org Fri May 16 01:18:51 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 15 May 2008 21:18:51 -0400 Subject: [Fedora-packaging] Retrograde package version In-Reply-To: <20080515235224.37355d9d@metropolis.intra.city-fan.org> References: <20080515175952.GA7325@imp.flyn.org> <27712.198.175.55.5.1210874540.squirrel@mail.jcomserv.net> <20080515223731.GB9619@imp.flyn.org> <20080515235224.37355d9d@metropolis.intra.city-fan.org> Message-ID: <20080516011851.GA17470@imp.flyn.org> >>>> I released a bugfix in the form of: >>>> >>>> mt-daapd-0.9-0.4.1696.fc8 >>>> mt-daapd-0.9-0.2.1696.fc9 >>>> mt-daapd-0.9-0.2.1696.el5 >>>> >>>> I had thought that the next release would be in the 0.9 series. >>>> >>>> Now, the bugfix is upstream and the author has released the next >>>> version of mt-daapd. Unfortunately, this version is 0.2.4.2, which >>>> is lower that the versions above. I'd like to supercede the >>>> packages above with this "lower" version number. >>>> >>>> What is the best way to handle this? I'd like to avoid using the >>>> 0.9 version, as the developer has not moved to this yet upstream. >>> Epoch bump? >> As far as I know, the epoch does not override the version for the >> update path. > Overriding the version is the entire raison d'?tre of epoch, isn't it? Please excuse my ignorance. I have read up on the epoch and you are right -- it provides the solution to my problem. Thanks! -- Mike :wq From ghosler at redhat.com Mon May 19 01:40:02 2008 From: ghosler at redhat.com (Gregory Hosler) Date: Mon, 19 May 2008 09:40:02 +0800 Subject: [Fedora-packaging] New packager question Message-ID: <4830DA72.2010408@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, new packager here. Apologies in advance for any ignorant questions. :) I'm the package maintainer/co-maintainer and I am now getting ready to do my first package update (the original commit was done for me :). I have been thru the PackageMaintainers/UpdatingPackageHowTo wiki. I have setup my cvs stage area. That was straight forward. I now am preparing to update the fedora package from upstream. The recent upstream package updates (i.e. since the original commit to fedora) include not only a new source tarball, but in addition, some spec file changes (to incorporate a division of sub-packages, as well as re-arrange the directory structure of the package deployment layout, stuff like that). As I walk thru the PackageMaintainers/UpdatingPackageHowTo, it instructs me how to setup cvs (done), import my new tarball to the devel branch and then to do a make. But I am not seeing how my new (changed) spec file is to be integrated into the structure. First question: What is the procedure when there are changes to the spec file ? Next, as I study PackageMaintainers/UpdatingPackageHowTo and my cvs area, in my cvs area I see {common, CVS, devel, EL-4, EL-5, F-7, F-8, F-9} CVS I understand. and I understand that the {EL-4, EL-5, F-7, F-8, F-9} sub dirs are for the different fedora/epel repos. I'm lacking some clarity as to the migration of files from devel to {EL-4, EL-5, F-7, F-8, F-9}, and/or {common} I am gathering that changes are done in devel first, and then after they build correctly, those changes/updates are then applied to the respective branch from {EL-4, EL-5, F-7, F-8, F-9}, one at a time. Is this correct ? now, the pc I'm using for development is presently F-8, i386; How do I verify a package for other platforms, other hardware ? I have heard of mock, koji, and have been to the relevant wiki pages. I'm more needing some step-by-step guidance, as to what needs to be done, and the order of things :) I'm guessing that once I've been thru this once or twice, it'll become 2nd nature, so please bear with me thru this introduction :) Any help / suggestions / (and esp) clarifications regarding the above, are most welcome. All the best, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMNpw404fl/0CV/QRAklfAKC/+IMlDOsv9VgxtEHR0D8KGzKTdwCfTZS3 a5nTCfd6S0ETA1Xa8KR0CLs= =toZE -----END PGP SIGNATURE----- From ivazqueznet at gmail.com Mon May 19 03:46:26 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 18 May 2008 23:46:26 -0400 Subject: [Fedora-packaging] New packager question In-Reply-To: <4830DA72.2010408@redhat.com> References: <4830DA72.2010408@redhat.com> Message-ID: <1211168787.31688.50.camel@ignacio.lan> On Mon, 2008-05-19 at 09:40 +0800, Gregory Hosler wrote: > Hi all, > > new packager here. > > Apologies in advance for any ignorant questions. The only ignorant questions are the ones unasked. > First question: What is the procedure when there are changes to the spec file ? cvs update ; $EDITOR foo.spec ; cvs commit > I am gathering that changes are done in devel first, and then after they build correctly, > those changes/updates are then applied to the respective branch from {EL-4, EL-5, F-7, > F-8, F-9}, one at a time. Is this correct ? It's best to keep newer releases with newer ENVRs, but there's no requirement to wait until a build is complete in devel before applying it to the stable Fedora releases. You can use the mockbuild target to give a "quick" shakedown of your package under a specific branch. EPEL has it's own set of rules; you'll want advice from someone that's more familiar with them before touching the EL branches. > now, the pc I'm using for development is presently F-8, i386; How do I verify a package > for other platforms, other hardware ? I have heard of mock, koji, and have been to the > relevant wiki pages. I'm more needing some step-by-step guidance, as to what needs to be > done, and the order of things :) You can pass --scratch to koji in order to test build a SRPM for a single release across all archs; I'm not sure if you can do a scratch build of the contents of a branch. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From zing at fastmail.fm Mon May 19 04:12:23 2008 From: zing at fastmail.fm (Zing) Date: Mon, 19 May 2008 04:12:23 +0000 (UTC) Subject: [Fedora-packaging] Re: New packager question References: <4830DA72.2010408@redhat.com> Message-ID: On Mon, 19 May 2008 09:40:02 +0800, Gregory Hosler wrote: > First question: What is the procedure when there are changes to the spec > file ? You can just edit the spec file directly in your cvs working copy and then "cvs commit" it. Yeah, it isn't directly clear in the howto, although step 2 does mention "cvs add"ing files. > Next, as I study PackageMaintainers/UpdatingPackageHowTo and my cvs > area, in my cvs area I see {common, CVS, devel, EL-4, EL-5, F-7, F-8, > F-9} CVS I understand. and I understand that the {EL-4, EL-5, F-7, F-8, > F-9} sub dirs are for the different fedora/epel repos. I'm lacking some > clarity as to the migration of files from devel to {EL-4, EL-5, F-7, > F-8, F-9}, and/or {common} > > I am gathering that changes are done in devel first, and then after they > build correctly, those changes/updates are then applied to the > respective branch from {EL-4, EL-5, F-7, F-8, F-9}, one at a time. Is > this correct ? If you mean that the changes happen automatically and flow from devel->EL, they don't... It's up to you to make changes in each of the different branches and then commit them separately. Use your best judgment as to when and where to update for the different versions (there is a guideline page about this somewhere, but i can't seem to find it in the wiki). EPEL is optional by the way, although I'm sure they'd love the help. > now, the pc I'm using for development is presently F-8, i386; How do I > verify a package for other platforms, other hardware ? I have heard of > mock, koji, and have been to the relevant wiki pages. I'm more needing > some step-by-step guidance, as to what needs to be done, and the order > of things :) there are some helpful make targets in your cvs checkout. type "make help": ... scratch-build Request scratch build of "xxx" for dist-f10 scratch-build- Request scratch build of "xxx" for dist-f10 and archs examples: make scratch-build-i386,ppc64 make scratch-build-x86_64 mockbuild Local test build using mock ... those make targets aren't really a step by step guide but they should "just work", (note: I actually haven't ever tried them :P). I have a local mock install that i setup manually some time ago that i use by hand and scratch-builds are a relatively recent thing. welcome aboard. From pertusus at free.fr Mon May 19 07:12:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 May 2008 09:12:59 +0200 Subject: [Fedora-packaging] New packager question In-Reply-To: <4830DA72.2010408@redhat.com> References: <4830DA72.2010408@redhat.com> Message-ID: <20080519071259.GA2525@free.fr> On Mon, May 19, 2008 at 09:40:02AM +0800, Gregory Hosler wrote: > > Next, as I study PackageMaintainers/UpdatingPackageHowTo and my cvs area, in my cvs area I > see {common, CVS, devel, EL-4, EL-5, F-7, F-8, F-9} CVS I understand. and I understand > that the {EL-4, EL-5, F-7, F-8, F-9} sub dirs are for the different fedora/epel repos. I'm > lacking some clarity as to the migration of files from devel to {EL-4, EL-5, F-7, F-8, > F-9}, and/or {common} F-7 is end of life so you shouldn't change it. Otherwise it is up to the packager. However you should think about what is best for your users depending on the target of the package (are these users who like the latest package, or do they prefer to stick to a version in old releases?). If you want to have maximal testing of your package, and since we are at th ebeginning of a new release cycle for F-10, you can wait for the devel version to be tested to push it to F-9 and F-8 and wait for testing in bodhi in these branches. However, if the user base is restricted, and the users don't know bodhi, having the release hit F-8 and F-9 as soon as possible may also be an option. For EPEL you should be very cautious, and read: http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies I personally think that it is bad to break ABI in releases, or do updates that have incompatible configuration files, but there are differing opinions on that matter. Which package is it? -- Pat From ghosler at redhat.com Mon May 19 10:30:02 2008 From: ghosler at redhat.com (Gregory Hosler) Date: Mon, 19 May 2008 18:30:02 +0800 Subject: [Fedora-packaging] New packager question In-Reply-To: <20080519071259.GA2525@free.fr> References: <4830DA72.2010408@redhat.com> <20080519071259.GA2525@free.fr> Message-ID: <483156AA.909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrice Dumas wrote: | On Mon, May 19, 2008 at 09:40:02AM +0800, Gregory Hosler wrote: |> Next, as I study PackageMaintainers/UpdatingPackageHowTo and my cvs area, in my cvs area I |> see {common, CVS, devel, EL-4, EL-5, F-7, F-8, F-9} CVS I understand. and I understand |> that the {EL-4, EL-5, F-7, F-8, F-9} sub dirs are for the different fedora/epel repos. I'm |> lacking some clarity as to the migration of files from devel to {EL-4, EL-5, F-7, F-8, |> F-9}, and/or {common} | | F-7 is end of life so you shouldn't change it. | | Otherwise it is up to the packager. However you should think about what | is best for your users depending on the target of the package (are these | users who like the latest package, or do they prefer to stick to a | version in old releases?). If you want to have maximal testing of your | package, and since we are at the beginning of a new release cycle for | F-10, you can wait for the devel version to be tested to push it to F-9 | and F-8 and wait for testing in bodhi in these branches. So you're saying that anything committed to devel will eventually find it's way to the other branches (F-*) ? | However, if the | user base is restricted, and the users don't know bodhi, having the | release hit F-8 and F-9 as soon as possible may also be an option. | | For EPEL you should be very cautious, and read: | http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies Thanks for that. | I personally think that it is bad to break ABI in releases, or do | updates that have incompatible configuration files, but there | are differing opinions on that matter. Which package is it ? gyachi -- it's an instant messaging package, lots of eye candy. does yahoo protocol. | -- | Pat | | -- | Fedora-packaging mailing list | Fedora-packaging at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-packaging - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMVao404fl/0CV/QRAn8cAKCkzGFv3LTNTDDEKkIdplCrx38r6ACeMymb /bwLlllk+ih47IMF7J7vONg= =sn7k -----END PGP SIGNATURE----- From pertusus at free.fr Mon May 19 10:46:43 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 May 2008 12:46:43 +0200 Subject: [Fedora-packaging] New packager question In-Reply-To: <483156AA.909@redhat.com> References: <4830DA72.2010408@redhat.com> <20080519071259.GA2525@free.fr> <483156AA.909@redhat.com> Message-ID: <20080519104643.GA2529@free.fr> On Mon, May 19, 2008 at 06:30:02PM +0800, Gregory Hosler wrote: > > So you're saying that anything committed to devel will eventually find it's way to the > other branches (F-*) ? No, it will find its way to F-10 only. You should make the changes you want to the other branches yourself. > | I personally think that it is bad to break ABI in releases, or do > | updates that have incompatible configuration files, but there > | are differing opinions on that matter. Which package is it ? > > gyachi -- it's an instant messaging package, lots of eye candy. does yahoo protocol. Looks like there is no library, but a plugin system, so there are issues of ABI compatibility, though you should know if they broke the plugins API for plugins that are not shipped with the main program. If no, my advice would be to push it to all the branches unless the new release is not compatible with previous user config, but I hope they didn't do something like that. -- Pat From ghosler at redhat.com Mon May 19 10:42:52 2008 From: ghosler at redhat.com (Gregory Hosler) Date: Mon, 19 May 2008 18:42:52 +0800 Subject: [Fedora-packaging] New packager question In-Reply-To: <1211168787.31688.50.camel@ignacio.lan> References: <4830DA72.2010408@redhat.com> <1211168787.31688.50.camel@ignacio.lan> Message-ID: <483159AC.1010409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignacio Vazquez-Abrams wrote: | On Mon, 2008-05-19 at 09:40 +0800, Gregory Hosler wrote: |> Hi all, |> |> new packager here. |> |> Apologies in advance for any ignorant questions. | | The only ignorant questions are the ones unasked. | |> First question: What is the procedure when there are changes to the spec file ? | | cvs update ; $EDITOR foo.spec ; cvs commit | |> I am gathering that changes are done in devel first, and then after they build correctly, |> those changes/updates are then applied to the respective branch from {EL-4, EL-5, F-7, |> F-8, F-9}, one at a time. Is this correct ? | | It's best to keep newer releases with newer ENVRs, but there's no | requirement to wait until a build is complete in devel before applying | it to the stable Fedora releases. You can use the mockbuild target to | give a "quick" shakedown of your package under a specific branch. ok, so if I understand properly... cvs update go to the devel, directory, update the spec file, then cvs commit (And to clarify, the above commit should be delayed until several steps below, where I have done a build on my system, yes?) and then make new-sources FILES="yournewtarball.tar.gz" Q: Do I have the tarball in the current (devel, or whatever) directory, or do I just specify the path to it, and "it doesn't matter" ? Q: does the above line push the new tarball into cvs ? or do i need a commit ? and then (if I understand correctly): make i386 will make an i386 package on my current i386 system yes ? Once I have a successful build cvs commit make tag make build (all above 3 lines from the devel directory). I'm terribly paranoid about submitting a package that will break while building, even though I've built it many times in my own environment... Devel builds goes where ? F-10 ? F-9 ? rawhide ? Thanks, and best rgds, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMVmq404fl/0CV/QRAl/gAJ42wZ9dTMu+ihxjnDFuiQwl/MPdQgCbBCaj Q/DIPwCnoC8k9rcStBLX/Tg= =1eL2 -----END PGP SIGNATURE----- From ghosler at redhat.com Mon May 19 10:53:16 2008 From: ghosler at redhat.com (Gregory Hosler) Date: Mon, 19 May 2008 18:53:16 +0800 Subject: [Fedora-packaging] New packager question In-Reply-To: <20080519104643.GA2529@free.fr> References: <4830DA72.2010408@redhat.com> <20080519071259.GA2525@free.fr> <483156AA.909@redhat.com> <20080519104643.GA2529@free.fr> Message-ID: <48315C1C.4070604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrice Dumas wrote: | On Mon, May 19, 2008 at 06:30:02PM +0800, Gregory Hosler wrote: |> So you're saying that anything committed to devel will eventually find it's way to the |> other branches (F-*) ? | | No, it will find its way to F-10 only. You should make the changes you | want to the other branches yourself. Ok. makes sense. So once I feel comfortable with the devel build, I then re-do my changes for the other F-* branches. Q: How do I monitor/track/follow whether there were any issues for a devel commit, for any other platform. e.g. x32_64 -- i.e. how frequently are builds done, and when are teh results known ? Q: ditto on the other branches (F-9, F-8, etc.) |> | I personally think that it is bad to break ABI in releases, or do |> | updates that have incompatible configuration files, but there |> | are differing opinions on that matter. Which package is it ? |> |> gyachi -- it's an instant messaging package, lots of eye candy. does yahoo protocol. | | Looks like there is no library, but a plugin system, so there are issues of | ABI compatibility, though you should know if they broke the plugins API | for plugins that are not shipped with the main program. If no, my advice | would be to push it to all the branches unless the new release is not | compatible with previous user config, but I hope they didn't do | something like that. I'm the principle maintainer, so I have "inside knowledge" of the ABI issues... The version I will be pushing will create a library that is a collection of common routines that are shared between the different package components. It's really a "private" library, and doesn't really have any practical use outside of the package. That being the case, I'll none-the-less keep an eye on the ABI aspect of the library. At the moment, adding external plugin's is not feasible (yet). True plugin support, requires that the plug in add a "hook" into the menu sub-system, so that the plugin can be called (or effects to that nature, for non-menu related plugins). At the moment, that layer (allowing a plugin to add a menu item, so as to invoke it's callbacks) is not there. Obviously this has been thought about, and it is planned. At THAt point ABI compatibility will be a much bigger issue. :) So, for now, there aren't ABI issues... Many thanks for your responses, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMVwa404fl/0CV/QRAnYdAJ9G7hx7lhNHI8S3cAJ2Vsoj/RE6AgCgu4Ln 0MKrxlzG9iOE53Rf8n46pnI= =KN/Q -----END PGP SIGNATURE----- From wolters.liste at gmx.net Mon May 19 15:47:42 2008 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 19 May 2008 17:47:42 +0200 Subject: [Fedora-packaging] Broken dependency /bin/sh? Message-ID: <200805191747.48080.wolters.liste@gmx.net> Hi list, I recently got error messages for all my (three) packages stating a broken dependency: ktorrent has broken dependencies in the development tree: On ppc: ktorrent-3.0.2-3.fc10.ppc64 requires /bin/sh On ... I'm not sure what the cause of this is, and what I should do about. Should I add /bin/sh as a fixed dependency? Roland -- Typical Canadian wimpiness! That's why you have snowballs and we have the H-bomb! -- Simpsons -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Mon May 19 15:59:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 May 2008 11:59:41 -0400 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <200805191747.48080.wolters.liste@gmx.net> References: <200805191747.48080.wolters.liste@gmx.net> Message-ID: <1211212781.7438.4.camel@localhost.localdomain> On Mon, 2008-05-19 at 17:47 +0200, Roland Wolters wrote: > > I'm not sure what the cause of this is, and what I should do about. Should I > add /bin/sh as a fixed dependency? This was a bug in yum one day that caused filedeps to not resolve. This has since been fixed so you can safely ignore the broken dep report that you got. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Mon May 19 16:14:05 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 May 2008 17:14:05 +0100 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <1211212781.7438.4.camel@localhost.localdomain> References: <200805191747.48080.wolters.liste@gmx.net> <1211212781.7438.4.camel@localhost.localdomain> Message-ID: <4831A74D.6000105@city-fan.org> Jesse Keating wrote: > On Mon, 2008-05-19 at 17:47 +0200, Roland Wolters wrote: >> I'm not sure what the cause of this is, and what I should do about. Should I >> add /bin/sh as a fixed dependency? > > This was a bug in yum one day that caused filedeps to not resolve. This > has since been fixed so you can safely ignore the broken dep report that > you got. As this isn't the first time that this (broken deps reports citing missing /bin/sh etc.) has happened, would it not be possible to add a sanity check on the broken deps script to avoid the mails if "obvious" things like /bin/sh are seen not to be available? Paul. From jkeating at redhat.com Mon May 19 16:33:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 May 2008 12:33:20 -0400 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <4831A74D.6000105@city-fan.org> References: <200805191747.48080.wolters.liste@gmx.net> <1211212781.7438.4.camel@localhost.localdomain> <4831A74D.6000105@city-fan.org> Message-ID: <1211214800.7438.7.camel@localhost.localdomain> On Mon, 2008-05-19 at 17:14 +0100, Paul Howarth wrote: > As this isn't the first time that this (broken deps reports citing > missing /bin/sh etc.) has happened, would it not be possible to add a > sanity check on the broken deps script to avoid the mails if "obvious" > things like /bin/sh are seen not to be available? It's possible sure. Just not something I'm probably going to get time to do. The code is in the releng git repo, in the scripts/ dir http://git.fedorahosted.org/git/?p=releng;a=summary -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Mon May 19 16:46:43 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 May 2008 11:46:43 -0500 Subject: [Fedora-packaging] New packager question In-Reply-To: <48315C1C.4070604@redhat.com> References: <4830DA72.2010408@redhat.com> <20080519071259.GA2525@free.fr> <483156AA.909@redhat.com> <20080519104643.GA2529@free.fr> <48315C1C.4070604@redhat.com> Message-ID: >>>>> "GH" == Gregory Hosler writes: GH> Q: How do I monitor/track/follow whether there were any issues for GH> a devel commit, for any other platform. e.g. x32_64 -- i.e. how GH> frequently are builds done, and when are teh results known ? Builds are generally done when you do them, although occasionally you'll find that someone rebuilds one of your packages. As the package owner, you'll get mail about every commit made to your packages and every build attempt. GH> Q: ditto on the other branches (F-9, F-8, etc.) No different. - J< From pertusus at free.fr Mon May 19 16:56:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 May 2008 18:56:17 +0200 Subject: [Fedora-packaging] New packager question In-Reply-To: <48315C1C.4070604@redhat.com> References: <4830DA72.2010408@redhat.com> <20080519071259.GA2525@free.fr> <483156AA.909@redhat.com> <20080519104643.GA2529@free.fr> <48315C1C.4070604@redhat.com> Message-ID: <20080519165617.GA2543@free.fr> On Mon, May 19, 2008 at 06:53:16PM +0800, Gregory Hosler wrote: > > Ok. makes sense. So once I feel comfortable with the devel build, I then re-do my changes > for the other F-* branches. Yes. In some cases (namely security bugs), you should also push to other branches as fast as possible. -- Pat From wolters.liste at gmx.net Mon May 19 16:59:27 2008 From: wolters.liste at gmx.net (Roland Wolters) Date: Mon, 19 May 2008 18:59:27 +0200 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <1211212781.7438.4.camel@localhost.localdomain> References: <200805191747.48080.wolters.liste@gmx.net> <1211212781.7438.4.camel@localhost.localdomain> Message-ID: <200805191859.32140.wolters.liste@gmx.net> Hi Jesse, Once upon a time Jesse Keating wrote: > On Mon, 2008-05-19 at 17:47 +0200, Roland Wolters wrote: > > I'm not sure what the cause of this is, and what I should do about. > > Should I add /bin/sh as a fixed dependency? > > This was a bug in yum one day that caused filedeps to not resolve. This > has since been fixed so you can safely ignore the broken dep report that > you got. > Perfect, and thx for the quick information :) Roland -- Friede kann nicht von M?chten erhalten werden, er kann nur durch Verst?ndnis erreicht werden. -- Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Mon May 19 18:20:47 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 19 May 2008 14:20:47 -0400 Subject: [Fedora-packaging] jpp naming exception Message-ID: <1211221247.3801.214.camel@localhost.localdomain> Hi FPC members, I would like to propose that we eliminate the jpp naming exception. I think that Bill Nottingham summarized the issue nicely: ok, as far as I can see: jpackage wants (the equivalent of) repotags we do not support repotags in fedora we have grandfathered in a %{release} hack for jpacakge for a while we'd like to get rid of that if they're going to insist that anything done to get rid of that is unacceptable because it's not a repotag... oh well but yum-priorities is a 'better' solution for repotags than Group-hackery :) I would agree with this assessment, and accordingly, I would like us to vote to eliminate the jpp naming exception during tomorrows meeting. Bring your flame-retardant underwear, but I would like to put this to bed. A few points to keep in mind: 1. This is solely about the naming exception in Fedora, not in any other repositories. 2. We do not permit repotags in any other scenario in Fedora. 3. Using the yum-priorities plugin permits weighting a third party repository over Fedora for packages. As usual, FESCo will have to ratify this. Thanks in advance, ~spot From opensource at till.name Mon May 19 18:23:58 2008 From: opensource at till.name (Till Maas) Date: Mon, 19 May 2008 20:23:58 +0200 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <1211214800.7438.7.camel@localhost.localdomain> References: <200805191747.48080.wolters.liste@gmx.net> <4831A74D.6000105@city-fan.org> <1211214800.7438.7.camel@localhost.localdomain> Message-ID: <200805192024.05889.opensource@till.name> On Mon May 19 2008, Jesse Keating wrote: > On Mon, 2008-05-19 at 17:14 +0100, Paul Howarth wrote: > > As this isn't the first time that this (broken deps reports citing > > missing /bin/sh etc.) has happened, would it not be possible to add a > > sanity check on the broken deps script to avoid the mails if "obvious" > > things like /bin/sh are seen not to be available? > > It's possible sure. Just not something I'm probably going to get time > to do. The code is in the releng git repo, in the scripts/ dir > > http://git.fedorahosted.org/git/?p=releng;a=summary I believe it is somewhere else because a "grep -Ri broken *" on a cloned repository did not show the "Broken dependencies" subject that the mails should have. I want to suggest to add a check whether or not the amount of broken packages is sane, e.g. up to 100. And in case it is not, the script could add a note to the mail sent to fedora-devel and maybe releng or whover would have to take a look then or only skip the individual reports. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dominik at greysector.net Mon May 19 18:32:25 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 19 May 2008 20:32:25 +0200 Subject: [Fedora-packaging] jpp naming exception In-Reply-To: <1211221247.3801.214.camel@localhost.localdomain> References: <1211221247.3801.214.camel@localhost.localdomain> Message-ID: <20080519183225.GB2962@ryvius.greysector.net> On Monday, 19 May 2008 at 20:20, Tom spot Callaway wrote: [...] > I would agree with this assessment, and accordingly, I would like us to > vote to eliminate the jpp naming exception during tomorrows meeting. > Bring your flame-retardant underwear, but I would like to put this to > bed. As this is important, and since I might not make it to the meeting tomorrow (or at least be late), let me post my vote for the record: +1. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jkeating at redhat.com Mon May 19 18:33:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 May 2008 14:33:49 -0400 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <200805192024.05889.opensource@till.name> References: <200805191747.48080.wolters.liste@gmx.net> <4831A74D.6000105@city-fan.org> <1211214800.7438.7.camel@localhost.localdomain> <200805192024.05889.opensource@till.name> Message-ID: <1211222029.7438.12.camel@localhost.localdomain> On Mon, 2008-05-19 at 20:23 +0200, Till Maas wrote: > > I believe it is somewhere else because a "grep -Ri broken *" on a cloned > repository did not show the "Broken dependencies" subject that the mails > should have. I want to suggest to add a check whether or not the amount of > broken packages is sane, e.g. up to 100. And in case it is not, the script > could add a note to the mail sent to fedora-devel and maybe releng or whover > would have to take a look then or only skip the individual reports. Gah, you're right. buildrawhide is in releng, but spam-o-matic comes from mash. http://git.fedorahosted.org/git/?p=mash -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon May 19 18:39:01 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 May 2008 14:39:01 -0400 Subject: [Fedora-packaging] jpp naming exception In-Reply-To: <1211221247.3801.214.camel@localhost.localdomain> References: <1211221247.3801.214.camel@localhost.localdomain> Message-ID: <1211222341.7438.17.camel@localhost.localdomain> On Mon, 2008-05-19 at 14:20 -0400, Tom "spot" Callaway wrote: > I would agree with this assessment, and accordingly, I would like us to > vote to eliminate the jpp naming exception during tomorrows meeting. > Bring your flame-retardant underwear, but I would like to put this to > bed. While I'm not in the Fedora Packaging Committee anymore, I do have some history with this little bit of goo. I agree with spot and notting in that we've done our due dilligance to provide alternatives to http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP and if jpackage doesn't like those, really that's on them to fix now. As far as Fedora users who may also be jpackage users there are more deterministic and reliable methods to achieve the technical goals listed above. At the end of the day that is who we have to service, the Fedora users. using repository priorities (via yum-priorities) solves the first three points on that page entirely. #4 is politics. #5 is a fragile metric, and really needs to be solved by developer<->developer conversation, rather than by package naming -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Mon May 19 19:30:55 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 19 May 2008 15:30:55 -0400 Subject: [Fedora-packaging] New packager question In-Reply-To: <483159AC.1010409@redhat.com> References: <4830DA72.2010408@redhat.com> <1211168787.31688.50.camel@ignacio.lan> <483159AC.1010409@redhat.com> Message-ID: <1211225456.31688.73.camel@ignacio.lan> On Mon, 2008-05-19 at 18:42 +0800, Gregory Hosler wrote: > ok, so if I understand properly... > > cvs update > > go to the devel, directory, update the spec file, then > > cvs commit > > (And to clarify, the above commit should be delayed until several steps below, where I > have done a build on my system, yes?) > > and then > > make new-sources FILES="yournewtarball.tar.gz" Uploading a new tarball frobs a couple of files in the branch, so you'll want to do that *before* committing. > Q: Do I have the tarball in the current (devel, or whatever) directory, or do I just > specify the path to it, and "it doesn't matter" ? I don't think it matters, but the process of building will download the source files to the branch directory regardless. > Q: does the above line push the new tarball into cvs ? or do i need a commit ? You need to commit after. > and then (if I understand correctly): > > make i386 > > will make an i386 package on my current i386 system yes ? It will build it using the packages you currently have installed on your system. Consider using make mockbuild instead. > Once I have a successful build > > cvs commit > make tag > make build > > (all above 3 lines from the devel directory). There's no hard requirement that you commit a completely-working build; nothing actually gets built until you direct koji/plague to do so. > I'm terribly paranoid about submitting a package that will break while building, even > though I've built it many times in my own environment... You don't get penalized for non-working builds, so don't worry. > Devel builds goes where ? F-10 ? F-9 ? rawhide ? Rawhide, which will currently eventually become F10. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dominik at greysector.net Mon May 19 19:51:32 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 19 May 2008 21:51:32 +0200 Subject: [Fedora-packaging] Using alternatives Message-ID: <20080519195132.GC2962@ryvius.greysector.net> Hi. While reviewing a package, I stumbled across the use of alternatives and found out it's not regulated in any way in Fedora. So far, I've encountered three ways of handling the symlinks that are set up using alternatives: 1. some packages have Provides: for them (like cups or postfix), 2. some don't own those files at all (like lam or scim), 3. some %ghost them. All seem to work, but in case of 2. it's not possible to find out which packages own/provide those files using rpm -qf, thus I consider it an inferior solution. Personally, I'm leaning towards 1., but I don't see any disadvantages in 3., either. Comments? Having said that, I'm going to write up a guideline to cover that. I expect to have a presentable draft ready in a week or two. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From opensource at till.name Mon May 19 20:17:35 2008 From: opensource at till.name (Till Maas) Date: Mon, 19 May 2008 22:17:35 +0200 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <1211222029.7438.12.camel@localhost.localdomain> References: <200805191747.48080.wolters.liste@gmx.net> <200805192024.05889.opensource@till.name> <1211222029.7438.12.camel@localhost.localdomain> Message-ID: <200805192217.36514.opensource@till.name> On Mon May 19 2008, Jesse Keating wrote: > Gah, you're right. buildrawhide is in releng, but spam-o-matic comes > from mash. > > http://git.fedorahosted.org/git/?p=mash Thanks, is it intended that there is no trac for mash? Where do I have to send patches to? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Mon May 19 21:01:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 May 2008 17:01:20 -0400 Subject: [Fedora-packaging] Broken dependency /bin/sh? In-Reply-To: <200805192217.36514.opensource@till.name> References: <200805191747.48080.wolters.liste@gmx.net> <200805192024.05889.opensource@till.name> <1211222029.7438.12.camel@localhost.localdomain> <200805192217.36514.opensource@till.name> Message-ID: <1211230880.25112.40.camel@localhost.localdomain> On Mon, 2008-05-19 at 22:17 +0200, Till Maas wrote: > > Thanks, is it intended that there is no trac for mash? Where do I have to send > patches to? Intended yes, Bill didn't want a trac page. They could go to a bugzilla against the mash package, or to fedora-buildsys-list -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Mon May 19 21:39:39 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 May 2008 23:39:39 +0200 Subject: [Fedora-packaging] Using alternatives In-Reply-To: <20080519195132.GC2962@ryvius.greysector.net> References: <20080519195132.GC2962@ryvius.greysector.net> Message-ID: <20080519213939.GB2826@free.fr> On Mon, May 19, 2008 at 09:51:32PM +0200, Dominik 'Rathann' Mierzejewski wrote: > Hi. > > While reviewing a package, I stumbled across the use of alternatives > and found out it's not regulated in any way in Fedora. So far, I've > encountered three ways of handling the symlinks that are set up using > alternatives: > 1. some packages have Provides: for them (like cups or postfix), Not all files are provided, only /usr/bin/mailq /usr/bin/newaliases /usr/bin/rmail /usr/sbin/sendmail while man pages are not provided. I think it is right like this. > 2. some don't own those files at all (like lam or scim), > 3. some %ghost them. > > All seem to work, but in case of 2. it's not possible to find out which > packages own/provide those files using rpm -qf, thus I consider it an > inferior solution. I don't think it is that important. Having that right would mean providing all the files in alternatives which could make a lot. In my opinion the provided files should be those that make sense to have as provides (or as yum install /usr/..../file). > Personally, I'm leaning towards 1., but I don't see any disadvantages > in 3., either. Comments? Doesn't %ghost leads to the file being removed? > Having said that, I'm going to write up a guideline to cover that. I expect > to have a presentable draft ready in a week or two. I don't think a guideline is needed, except if there are specific pitfalls. Some advices may be nice, though. I remember that I asked for some when I first got interested in fedora. -- Pat From notting at redhat.com Mon May 19 21:51:50 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 May 2008 17:51:50 -0400 Subject: [Fedora-packaging] Using alternatives In-Reply-To: <20080519213939.GB2826@free.fr> References: <20080519195132.GC2962@ryvius.greysector.net> <20080519213939.GB2826@free.fr> Message-ID: <20080519215150.GP27865@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > On Mon, May 19, 2008 at 09:51:32PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Hi. > > > > While reviewing a package, I stumbled across the use of alternatives > > and found out it's not regulated in any way in Fedora. So far, I've > > encountered three ways of handling the symlinks that are set up using > > alternatives: > > 1. some packages have Provides: for them (like cups or postfix), > > Not all files are provided, only > /usr/bin/mailq > /usr/bin/newaliases > /usr/bin/rmail > /usr/sbin/sendmail > while man pages are not provided. I think it is right like this. Files have to be 'provided' so things that depend on them can work. Hopefully nothing depends on man pages. Bill From rdieter at math.unl.edu Tue May 20 00:02:05 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 May 2008 19:02:05 -0500 Subject: [Fedora-packaging] Using alternatives In-Reply-To: <20080519195132.GC2962@ryvius.greysector.net> References: <20080519195132.GC2962@ryvius.greysector.net> Message-ID: <483214FD.9010208@math.unl.edu> Dominik 'Rathann' Mierzejewski wrote: > Hi. > > While reviewing a package, I stumbled across the use of alternatives > and found out it's not regulated in any way in Fedora. So far, I've > encountered three ways of handling the symlinks that are set up using > alternatives: > 1. some packages have Provides: for them (like cups or postfix), > 2. some don't own those files at all (like lam or scim), > 3. some %ghost them. > > All seem to work, but in case of 2. it's not possible to find out which > packages own/provide those files using rpm -qf, thus I consider it an > inferior solution. > > Personally, I'm leaning towards 1., but I don't see any disadvantages > in 3., either. Comments? My preference in order is: 3, 1, 2. 2 is least desirable, imo, mostly because abhor unowned files. -- Rex From jkeating at redhat.com Tue May 20 03:09:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 May 2008 23:09:02 -0400 Subject: [Fedora-packaging] [Fwd: [JPackage-discuss] Moving jpp# to Provides:] Message-ID: <1211252942.25112.55.camel@localhost.localdomain> I sent this over to the jpackage discussion list after a lengthy talk on IRC with a few Fedora and jpackage folks. So far there hasn't been any response other than some clarification of the rpm level drawback of using Provides. I thought I would toss it over here for some consideration on our side of things. -------- Forwarded Message -------- From: Jesse Keating Reply-To: Discussion about JPackage project To: Discussion about JPackage project Subject: [JPackage-discuss] Moving jpp# to Provides: Date: Mon, 19 May 2008 16:05:01 -0400 In trying to find a compromise for jpackage packages in Fedora, we asked somebody from the jpackage side to provide a list of technical reasons why 'jpp#' needed to continue to be in the Release: string of an rpm. Deepak provided us with http://fedoraproject.org/wiki/DeepakBhole/ReasonsForKeepingJPP In reviewing this and in the various arguments that have happened over the past few years surrounding the jpp vendor tag, I think I've struck upon something that just may work, at least work to the best of the requirements that I know of. If we simply move the 'jpp#' part of the release string to a Provides: line in the spec file, here is what happens: Exclusion of jpp* from a specific repo can still be done, since excludes work upon Provides too. It can be even more precise since currently a package with the name of foolalajpp4me would trigger the excludes and cause problems. Deploying an entire jpackage stack is still possible. This is actually better accomplished at the yum repo level. yum --disablerepo=\* --enablerepo=jpackage install \* <-- that will install everything from jpackage, which I am understanding is the goal of this data point. JPackage is still given credit as the package provides jpp, has the jpp changelogs, can have # comments regarding the jpackage interaction, summary, description, etc... Grouping by jpp is still possible. yum --disablerepo=\* --provides jpp* ---- A current drawback to using jpp# is that the '#' can change, so using rpm itself becomes more tricky as rpm doesn't accept globs. That said, instead of doing jpp# you could just do 'jpp' and then rpm would be able to do things like: rpm -q --whatprovides jpp and well, whatever you want to do with that output. However if you wanted to keep the versioning information, and still retain the ability to query on 'jpp', you could do: Provides: jpp = # or =< if that fills your needs. Since rpm does handle versioning in Provides you can still do rpm -q --whatprovides jpp and that will work. Anyway I'm drifting a bit here, but I did want to start a conversation about the feasibility of using Provides to accomplish the listed goals rather than added characters in the release string. I should also note that for best results, this Provides should be /added/ at both the jpackage and Fedora level. Removal of the jpp# information from release string technically only needs to be done at the Fedora level, it could remain at the jpackage level if so desired. The existence of "jpp#" can easily be controlled by a %{_dist} like tag in the release string. In jpackage build roots that value can expand to 'jpp#' and in Fedora buildroots that value would expand to '.fc#'. Since the other version-release parts should be used for version comparison it shouldn't much matter if jpp# is on the jpackage side and .fc# is on the Fedora side. _______________________________________________ JPackage-discuss mailing list JPackage-discuss at zarb.org https://www.zarb.org/mailman/listinfo/jpackage-discuss -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dominik at greysector.net Tue May 20 19:58:52 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 20 May 2008 21:58:52 +0200 Subject: [Fedora-packaging] Using alternatives In-Reply-To: <20080519213939.GB2826@free.fr> References: <20080519195132.GC2962@ryvius.greysector.net> <20080519213939.GB2826@free.fr> Message-ID: <20080520195852.GB3005@ryvius.greysector.net> On Monday, 19 May 2008 at 23:39, Patrice Dumas wrote: > On Mon, May 19, 2008 at 09:51:32PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Hi. > > > > While reviewing a package, I stumbled across the use of alternatives > > and found out it's not regulated in any way in Fedora. So far, I've > > encountered three ways of handling the symlinks that are set up using > > alternatives: > > 1. some packages have Provides: for them (like cups or postfix), > > Not all files are provided, only > /usr/bin/mailq > /usr/bin/newaliases > /usr/bin/rmail > /usr/sbin/sendmail > while man pages are not provided. I think it is right like this. I'm not so sure. I'd like to be able to tell what package provides sendmail(1) manpage. > > 2. some don't own those files at all (like lam or scim), > > 3. some %ghost them. > > > > All seem to work, but in case of 2. it's not possible to find out which > > packages own/provide those files using rpm -qf, thus I consider it an > > inferior solution. > > I don't think it is that important. Having that right would mean > providing all the files in alternatives which could make a lot. In my > opinion the provided files should be those that make sense to have as > provides (or as yum install /usr/..../file). > > > Personally, I'm leaning towards 1., but I don't see any disadvantages > > in 3., either. Comments? > > Doesn't %ghost leads to the file being removed? If only one package was installed, the file would be removed, but if there are two that %ghost the same file, it stays until the last package owning it is removed. > > Having said that, I'm going to write up a guideline to cover that. I expect > > to have a presentable draft ready in a week or two. > > I don't think a guideline is needed, except if there are specific > pitfalls. Some advices may be nice, though. I remember that I asked for > some when I first got interested in fedora. Well, *some* hints are definitely necessary. I was a bit in the dark when I tried to review a package that used alternatives and couldn't find any solid information, only different solutions. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From j.w.r.degoede at hhs.nl Wed May 21 04:45:48 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 21 May 2008 06:45:48 +0200 Subject: [Fedora-packaging] My absence at yesterdays FPC meeting Message-ID: <4833A8FC.2070109@hhs.nl> Hi All, Sorry for not being there yesterday (again), I'm currently in a bit of a rough spot / time in my personal (well actually paid work) life. Its not that I cannot be there, its more that I just have so much on my mind I forgot. Apologies. Regards, Hans From fedora at leemhuis.info Wed May 21 06:31:36 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 May 2008 08:31:36 +0200 Subject: [Fedora-packaging] shipping distribution-specific patches *separately* Message-ID: <4833C1C8.7080803@leemhuis.info> Hi! Quoting a paragraph from: http://lwn.net/Articles/283030/ > Debian's packaging policy resembles that of most other distributions. > A Debian source package is supposed to contain a tarball of the > upstream source distribution, without changes. Any > distribution-specific patches are included separately and applied > when the source package is prepared for building. Do we have a policy that all patches we apply in our packages need to be included *separately*? (I couldn't find anything like that in our guidelines, but maybe I missed it) And if not: Do we want such a statement in our guidelines? Background: I wanted to use grub as provided by Fedora on a FAT partition. That didn't work properly, as the Fedora grub includes this patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-7/grub-0.93-configfile.patch?view=markup The main part of it (?): - .string "/boot/grub/menu.lst" + .string "/boot/grub/grub.conf" That of course creates trouble, as FAT due to its 8.3 filemane limitations can't store a file called grub.conf. Thus I had to build a special grub where this patch wasn't applied. That was no big deal and at least for me a easy thing to do. In F8 and later that's way harder, as there is one patch (created from git afaics) where all the patches that in F-7 were applied separately are now merged into one giant 1,6 MByte big patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-8/grub-fedora-8.patch?view=markup Building grub without that one patch of course is way harder now, as I need to get my hands on that one patch and revert it after the giant patch was applied. Not impossible, but way harder if one doesn't know where to find that one small patch to revert it. Do we care or do we want to ignore this (minor) issue? CU knurd (?) Side note: I think it's wrong to add such a patch, as differing from upstream in things like config file naming just creates trouble and confusion for everyone. From rc040203 at freenet.de Wed May 21 08:04:22 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 May 2008 10:04:22 +0200 Subject: [Fedora-packaging] shipping distribution-specific patches *separately* In-Reply-To: <4833C1C8.7080803@leemhuis.info> References: <4833C1C8.7080803@leemhuis.info> Message-ID: <1211357062.26792.1673.camel@beck.corsepiu.local> On Wed, 2008-05-21 at 08:31 +0200, Thorsten Leemhuis wrote: > Hi! > > Quoting a paragraph from: > http://lwn.net/Articles/283030/ > > > Debian's packaging policy resembles that of most other distributions. > > A Debian source package is supposed to contain a tarball of the > > upstream source distribution, without changes. Any > > distribution-specific patches are included separately and applied > > when the source package is prepared for building. > > Do we have a policy that all patches we apply in our packages need to be > included *separately*? None that I am aware about, except that we ask/encourage packagers to use clean upstream tarballs. As a consequence of this, we have a similar rule in effect. > Do we care or do we want to ignore this (minor) issue? IMO, we should. > (?) Side note: I think it's wrong to add such a patch, as differing from > upstream in things like config file naming just creates trouble and > confusion for everyone. Agreed. Shipping customized tarballs, where an upstream is available should be banned. Ralf From a.badger at gmail.com Wed May 21 10:54:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 21 May 2008 03:54:15 -0700 Subject: [Fedora-packaging] shipping distribution-specific patches *separately* In-Reply-To: <4833C1C8.7080803@leemhuis.info> References: <4833C1C8.7080803@leemhuis.info> Message-ID: <4833FF57.6070208@gmail.com> Thorsten Leemhuis wrote: > Hi! > > Quoting a paragraph from: > http://lwn.net/Articles/283030/ > >> Debian's packaging policy resembles that of most other distributions. >> A Debian source package is supposed to contain a tarball of the >> upstream source distribution, without changes. Any >> distribution-specific patches are included separately and applied >> when the source package is prepared for building. > > Do we have a policy that all patches we apply in our packages need to be > included *separately*? (I couldn't find anything like that in our > guidelines, but maybe I missed it) And if not: Do we want such a > statement in our guidelines? > AFAIK, Debian is worse off than we are here. dpkg itself can only take a single patch file. Many Debian maintainers keep separate patches in their source tree but those are changed into a single patch by the time the .deb is built. The lwn article probably means "separately" as in "separate from the tarball". > Background: I wanted to use grub as provided by Fedora on a FAT > partition. That didn't work properly, as the Fedora grub includes this > patch: > http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-7/grub-0.93-configfile.patch?view=markup > > > The main part of it (?): > > - .string "/boot/grub/menu.lst" > + .string "/boot/grub/grub.conf" > > That of course creates trouble, as FAT due to its 8.3 filemane > limitations can't store a file called grub.conf. Thus I had to build a > special grub where this patch wasn't applied. That was no big deal and > at least for me a easy thing to do. > > In F8 and later that's way harder, as there is one patch (created from > git afaics) where all the patches that in F-7 were applied separately > are now merged into one giant 1,6 MByte big patch: > http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-8/grub-fedora-8.patch?view=markup > IIRC the history of grub is that only distributions care about the current stable release of grub. Upstream has been working on the next release only but it's not ready yet. This could be why we've switched from multiple patches to a single patch from source control... it's essentially a fork at this point. > Building grub without that one patch of course is way harder now, as I > need to get my hands on that one patch and revert it after the giant > patch was applied. Not impossible, but way harder if one doesn't know > where to find that one small patch to revert it. > > Do we care or do we want to ignore this (minor) issue? > I think we should care. We probably want something like: '''SHOULD''': Packages should keep patches that are only meant for Fedora (config changes, hacks to work around problems until a real answer is found) separate from packages suitable for upstream (bugfixes, enhancements, things that should be sent upstream). Alternately, this could be tied with the patch metadata-upstream policy that's in the works (as the primary metadata info is what's the status of this upstream). I'm not sure how this would apply to grub if my understanding of its history is accurate. Perhaps there needs to be an upstream project created for our fork. -Toshio From linux4michelle at tamay-dogan.net Fri May 23 21:53:33 2008 From: linux4michelle at tamay-dogan.net (Michelle Konzack) Date: Fri, 23 May 2008 23:53:33 +0200 Subject: [Fedora-packaging] How to make SRPMs and RPMs? Message-ID: <20080523215333.GI4288@freenet.de> Hello *, I am "new" to Fedora since I was using long time ago DLD (Deutsche Linux Distribution from Delix which was bougth by RedHat in 1999) and I need a little bit help to start. If this list is not the right one, please let me know. I am Debian GNU/Linux Consultant in Strasbourg and now have to work with RedHat and Fedora since my customers proprietary software does not work on ANY Debian machines. I need to package some software for my customer and like to know HOW to package it. Curently I run only Debian Unstable/Stable and I am doubt if I can create packages under Debian without installing a Xen Machine for it since learning the whole RedHat/Fedora thing is currently a little bit to much. Now I have some questions: 1) Where can I find the "Packaging Tutorial"? 2) Where can I find the "Guidelines for Packaging"? 3) Where can I find infos about the FSH (File System Hierarchy) since it is a little bit different from Debian? 4) What does I need to build my own private fedors mirror (RPMs and SRPMs) with GPG signed packages? 5) If I create my own private fedora mirror on my server, is it possibel under Fedora to have the mirror password protected? x) What should I know more? y) Is there a tutorial, "HOW TO INSTALL" a Fedora-Xen-DomU on a Debian host system. My Development station is a AMD Phenom Quad 9800 with 8 GByte of memory and 74 GByte SCI/SCA drives (one per guest OS). Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant Fedora Newbie :-) -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ ##################### Debian GNU/Linux Consultant ##################### Michelle Konzack Apt. 917 ICQ #328449886 +49/177/9351947 50, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.pgp Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Fedora at FamilleCollet.com Sat May 24 18:11:28 2008 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 24 May 2008 20:11:28 +0200 Subject: [Fedora-packaging] How to make SRPMs and RPMs? In-Reply-To: <20080523215333.GI4288@freenet.de> References: <20080523215333.GI4288@freenet.de> Message-ID: <48385A50.2020303@FamilleCollet.com> Michelle Konzack a ?crit : > > Now I have some questions: > > 1) Where can I find the "Packaging Tutorial"? http://www.rpm.org/max-rpm-snapshot/ > 2) Where can I find the "Guidelines for Packaging"? http://fedoraproject.org/wiki/Packaging/Guidelines > 3) Where can I find infos about the FSH (File System Hierarchy) > since it is a little bit different from Debian? http://www.pathname.com/fhs/ > 4) What does I need to build my own private fedors mirror (RPMs and > SRPMs) with GPG signed packages? see createrepo and yum-utils ++ From ivazqueznet at gmail.com Sat May 24 21:18:15 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 24 May 2008 17:18:15 -0400 Subject: [Fedora-packaging] How to make SRPMs and RPMs? In-Reply-To: <20080523215333.GI4288@freenet.de> References: <20080523215333.GI4288@freenet.de> Message-ID: <1211663895.3444.51.camel@ignacio.lan> On Fri, 2008-05-23 at 23:53 +0200, Michelle Konzack wrote: > 1) Where can I find the "Packaging Tutorial"? http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide > y) Is there a tutorial, "HOW TO INSTALL" a Fedora-Xen-DomU on a > Debian host system. My Development station is a AMD Phenom Quad > 9800 with 8 GByte of memory and 74 GByte SCI/SCA drives (one per > guest OS). There is virt-install, but I'm not sure how well it works from a non-Fedora distro. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From linux4michelle at tamay-dogan.net Sun May 25 16:27:48 2008 From: linux4michelle at tamay-dogan.net (Michelle Konzack) Date: Sun, 25 May 2008 18:27:48 +0200 Subject: [Fedora-packaging] Re: How to make SRPMs and RPMs? In-Reply-To: <20080523215333.GI4288@freenet.de> References: <20080523215333.GI4288@freenet.de> Message-ID: <20080525162748.GD2265@freenet.de> Another question: Is it posible to download the whole http://docs.fedoraproject.org/drafts/rpm-guide-en/ as tar ball for offline reading? I live in a region where I have no telephone/ADSL and GSM is quiet expensive for such things... Thanks, Greetings and nice Day Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ ##################### Debian GNU/Linux Consultant ##################### Michelle Konzack Apt. 917 ICQ #328449886 +49/177/9351947 50, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.pgp Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mr.ecik at gmail.com Sun May 25 20:10:09 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 25 May 2008 22:10:09 +0200 Subject: [Fedora-packaging] Re: How to make SRPMs and RPMs? In-Reply-To: <20080525162748.GD2265@freenet.de> References: <20080523215333.GI4288@freenet.de> <20080525162748.GD2265@freenet.de> Message-ID: <668bb39a0805251310iae92f8em702ae5f94c62833e@mail.gmail.com> 2008/5/25, Michelle Konzack : > Another question: Is it posible to download the whole > > http://docs.fedoraproject.org/drafts/rpm-guide-en/ > > as tar ball for offline reading? I live in a region where I have > no telephone/ADSL and GSM is quiet expensive for such things... Try to use wget to it: wget -r -l1 -p -k -nd http://docs.fedoraproject.org/drafts/rpm-guide-en/ The above command should do it. -- Micha? Bentkowski mr.ecik at gmail.com From sergio.pasra at gmail.com Fri May 30 22:07:55 2008 From: sergio.pasra at gmail.com (Sergio Pascual) Date: Sat, 31 May 2008 00:07:55 +0200 Subject: [Fedora-packaging] eclipse plugin without feature.xml Message-ID: <89b36810805301507g506404a5pdfd3a79a89e300c1@mail.gmail.com> Hello, I'm trying to package a eclipse plugin called veditor. I have followed the guidelines in wiki/Packaging/EclipsePlugins The zip with the source code contains a file plugin.xmll but doesn't contain feature.xml. When building, %{eclipse_base}/buildscripts/pdebuild -f net.sourceforge.veditor fails, because feature.xml doesn't exist. How do I build with plugin.xml but without feature.xml? Regards, Sergio From tibbs at math.uh.edu Sat May 31 01:23:09 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 May 2008 20:23:09 -0500 Subject: [Fedora-packaging] file-not-utf8 complaints Message-ID: Normally we fix up non-utf8 documentation and such with a quick call to iconv. It seems that this is problematic for some; see https://bugzilla.redhat.com/show_bug.cgi?id=226079 Any comments on how much we actually care about this, especially in the case that it might not actually be as easy as a call to iconv (such as a changelog file with a pile of random encodings in it). - J< From a.badger at gmail.com Sat May 31 01:56:33 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 30 May 2008 18:56:33 -0700 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: References: Message-ID: <4840B051.9040804@gmail.com> Jason L Tibbitts III wrote: > Normally we fix up non-utf8 documentation and such with a quick call > to iconv. It seems that this is problematic for some; see > https://bugzilla.redhat.com/show_bug.cgi?id=226079 > > Any comments on how much we actually care about this, especially in > the case that it might not actually be as easy as a call to iconv > (such as a changelog file with a pile of random encodings in it). > Well... The reason that all files must be UTF-8 is exactly the problem that the ChangeLog exhibits so I don't have a lot of sympathy there. The names and special characters in that file are already corrupted since there's no common encoding and none is recorded with the names. Dropping it from the package, as Daniel expressed is certainly an option as there's no requirement that ChangeLogs need to be in a package and it is not something that must be changed. Reencoding the xml files that specify an encoding isn't strictly necessary. We should probably ask upstream whether they are amenable to changing to utf-8. Since libxml2 deals with utf-8 internally and the upstream author made a nice writeup about why he made that choice, upstream might be amenable to that. If upstream is not amenable, we should consider changing the Packaging Guidelines to reflect that xml files which specify their encoding do not have to be re-encoded utf-8. (Although we then have to ask ourselves if we should be checking that the xml files actually use the encoding that they specify :-( NEWS and other files that are neither specifying an encoding nor mixed up in such a way that they are hopelessly corrupted WRT the original characters should definitely be converted to utf-8. If Daniel wants to hold open the Merge Review until that has gone in upstream, that is his perogative. The most chilling aspect of that review is that the maintainer does not seem to think that it's his responsibility to take issues with the upstream source to upstream. Since Daniel is upstream, I'm not certain I can see why he feels that someone else should be reporting it upstream before he deals with it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From j.w.r.degoede at hhs.nl Sat May 31 06:06:53 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 31 May 2008 08:06:53 +0200 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <4840B051.9040804@gmail.com> References: <4840B051.9040804@gmail.com> Message-ID: <4840EAFD.4090205@hhs.nl> Toshio Kuratomi wrote: > Jason L Tibbitts III wrote: >> Normally we fix up non-utf8 documentation and such with a quick call >> to iconv. It seems that this is problematic for some; see >> https://bugzilla.redhat.com/show_bug.cgi?id=226079 >> >> Any comments on how much we actually care about this, especially in >> the case that it might not actually be as easy as a call to iconv >> (such as a changelog file with a pile of random encodings in it). >> > Well... The reason that all files must be UTF-8 is exactly the problem > that the ChangeLog exhibits so I don't have a lot of sympathy there. +1, Although I fully agree with Daniel that blindly converting text-ish files which actually specify an encoding in their headers is both wrong and dangerous as that actually breaks stuff, normal text files, esp. ones in %doc should be in UTF-8, so that when opened they display correctly. Indeed the changelog is a perfect example of why all plain text files must be UTF-8, had it always been UTF-8 the problems between part being in west-european encoding and parts in east-european encoding would not exist. Also I think its worth noting that Fedora is not the only distro doing this, Debian for example also tries to have all text files in the distro in UTF-8. I'll also put a comment to this extend in the review. Regards, Hans The > names and special characters in that file are already corrupted since > there's no common encoding and none is recorded with the names. > Dropping it from the package, as Daniel expressed is certainly an option > as there's no requirement that ChangeLogs need to be in a package and it > is not something that must be changed. > > Reencoding the xml files that specify an encoding isn't strictly > necessary. We should probably ask upstream whether they are amenable to > changing to utf-8. Since libxml2 deals with utf-8 internally and the > upstream author made a nice writeup about why he made that choice, > upstream might be amenable to that. If upstream is not amenable, we > should consider changing the Packaging Guidelines to reflect that xml > files which specify their encoding do not have to be re-encoded utf-8. > (Although we then have to ask ourselves if we should be checking that > the xml files actually use the encoding that they specify :-( > > NEWS and other files that are neither specifying an encoding nor mixed > up in such a way that they are hopelessly corrupted WRT the original > characters should definitely be converted to utf-8. If Daniel wants to > hold open the Merge Review until that has gone in upstream, that is his > perogative. > > The most chilling aspect of that review is that the maintainer does not > seem to think that it's his responsibility to take issues with the > upstream source to upstream. Since Daniel is upstream, I'm not certain > I can see why he feels that someone else should be reporting it upstream > before he deals with it. > > -Toshio > > > ------------------------------------------------------------------------ > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From pertusus at free.fr Sat May 31 09:37:25 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 31 May 2008 11:37:25 +0200 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <4840B051.9040804@gmail.com> References: <4840B051.9040804@gmail.com> Message-ID: <20080531093725.GB2608@free.fr> On Fri, May 30, 2008 at 06:56:33PM -0700, Toshio Kuratomi wrote: >> > > Reencoding the xml files that specify an encoding isn't strictly > necessary. We should probably ask upstream whether they are amenable to I think that reencoding files that carry over the encoding information (info, texinfo, tex and xml for example) is wrong. It is better to let upstream do whatever they want. Same for examples of code, better leave the encoding preferred by upstream. For NEWS/Changelog, other text files in %doc and also man pages that are not installed in a non utf8 locale, I agree that converting to UTF-8 is better. -- Pat From a.badger at gmail.com Sat May 31 23:09:25 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 31 May 2008 16:09:25 -0700 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <20080531093725.GB2608@free.fr> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> Message-ID: <4841DAA5.7090807@gmail.com> Patrice Dumas wrote: > On Fri, May 30, 2008 at 06:56:33PM -0700, Toshio Kuratomi wrote: >> Reencoding the xml files that specify an encoding isn't strictly >> necessary. We should probably ask upstream whether they are amenable to > > I think that reencoding files that carry over the encoding information > (info, texinfo, tex and xml for example) is wrong. It is better to let > upstream do whatever they want. Same for examples of code, better leave > the encoding preferred by upstream. > > For NEWS/Changelog, other text files in %doc and also man pages that are > not installed in a non utf8 locale, I agree that converting to UTF-8 is > better. > I'm almost in complete agreement with you. The one extra piece that I think should be considered is how the text is normally viewed/edited. For instance, if a program has a plain text data file and the program expects the data to be encoded in utf-16 that should stay utf-16. Since the end user never views the file and the program has an expectation of what's in it, this should be perfectly acceptable. However, the flipside of this is if a program has an xml config file that the user is expected to edit manually in a text editor and the program will adapt to multiple encodings (for instance, by using libxml2 to parse the file[1]_) having it exist in utf-8 is much better than having it exist in SOME_EXOTIC_ENCODING. In this case it's the program that doesn't care that the config file is in utf-8 vs SHIFT-JIS. But the user that opens the file in a text editor will be presented with garbage if the text does not match the system default encoding. Yes, the user can manually change the encoding that is displayed and saved in some editors but: 1) This is not the full range of editors. 2) The user has to learn to enable the new encoding in their editor. This involves reading, editing, and saving. Some editors will display garbage unless you set the correct encoding on startup, others can change while running; some convert on open with a best guess at what the bytes mean but you have to specify what encoding to save the result otherwise you get the default (utf-8 or dependent on your locale settings). 3) If the user wants to use characters that are not present in the encoding the file is written in (for instance, the file is encoded in KOI8-R but the user wants to use kanji.) They'll have to convert the file to a unicode family of encodings and edit the header that tells the character set to use before making their changes. So really, whether the user is intended to edit/view the file directly instead of through a program that can change the encoding appropriately should be the dividing line rather than whether the format specifies the encoding/does not specify encoding. .. _[1]: http://xmlsoft.org/encoding.html#Default Whether this is something we should do in our packages even if upstream doesn't accept the changes involves other factors. In the case of documentation files that have no encoding we should convert whether or not upstream agrees. In the case of documentation that does specify the encoding I lean towards converting [2]_. In the case of a file that is used by a program we should definitely have a conversation with upstream about it, although we could convert locally with upstream's blessing (ie: Upstream says: "I'm going to continue writing my xml config file in latin-1. If you want to convert them to utf-8 for your users that's fine -- I'm going to continue to use a library for xml parsing that understands encodings.") .. _[2]: Note that this is only for documentation which is not supposed to be viewed directly. xhtml, for instance, is normally going to be viewed in a browser so this would not apply. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: