From Axel.Thimm at ATrpms.net Sun Feb 1 09:18:03 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Feb 2009 10:18:03 +0100 Subject: [Fedora-packaging] Re: Remove "Encoding=UTF-8" from sample desktop file In-Reply-To: <4984A55E.1000602@redhat.com> References: <49848D0C.5030306@fi.muni.cz> <4984A55E.1000602@redhat.com> Message-ID: <20090201091803.GC31604@teufli.physik.fu-berlin.de> Hi, On Sat, Jan 31, 2009 at 02:24:14PM -0500, Tom spot Callaway wrote: > On 2009-01-31 at 12:40:28 -0500, Milos Jakubicek wrote: > > yesterday when reviewing a package I noticed that although we have a > > MUST: follow the desktop-entry-spec in the Guidelines, the example on > > that page includes a line with: > > > > Encoding=UTF-8 > > > > which is deprecated according to: > > http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#legacy-mixed > > > > > > We should get rid of that line, as some people (including me) are taking > > that sample as a basis when creating new desktop files, shouldn't we? > > Yep. That line is gone now. is that compatible to siblings like RHEL4? -- Axel.Thimm at ATrpms.net From kanarip at kanarip.com Mon Feb 2 06:11:37 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 02 Feb 2009 07:11:37 +0100 Subject: [Fedora-packaging] Stupid question Message-ID: <49868E99.3090609@kanarip.com> Hey there, I've taken over the ruby package, which basically is the first core-component piece of software on my relatively small list of packages. Attached is a patch that was in ruby-1.8.6, and that I rebased to ruby-1.8.7. Since it's a really simple patch, I wonder why it's not upstream. I'm not sure what this fixes, in that ruby will build without the patch as well. I've searched through the logs to see if there's some kind of warning related to socket.c, but there is none from what I can tell. I'd love to learn what this patch does and then try and get upstream to accept it (so that I have less work to do). Can someone on this list help me with this? Thanks in advance, Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: ruby-1.8.7-p72-gcc43.patch Type: text/x-patch Size: 427 bytes Desc: not available URL: From jeff at ocjtech.us Mon Feb 2 06:30:57 2009 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 2 Feb 2009 00:30:57 -0600 Subject: [Fedora-packaging] Stupid question In-Reply-To: <49868E99.3090609@kanarip.com> References: <49868E99.3090609@kanarip.com> Message-ID: <935ead450902012230g295c3477j267c9bf8a0eade44@mail.gmail.com> On Mon, Feb 2, 2009 at 12:11 AM, Jeroen van Meeuwen wrote: > > I've taken over the ruby package, which basically is the first > core-component piece of software on my relatively small list of packages. > > Attached is a patch that was in ruby-1.8.6, and that I rebased to > ruby-1.8.7. Since it's a really simple patch, I wonder why it's not > upstream. > > I'm not sure what this fixes, in that ruby will build without the patch as > well. I've searched through the logs to see if there's some kind of warning > related to socket.c, but there is none from what I can tell. > > I'd love to learn what this patch does and then try and get upstream to > accept it (so that I have less work to do). Can someone on this list help me > with this? For a while back in February of '08 was some breakage in glibc where NI_MAXHOST wasn't defined anymore (at least not under the usual circumstances that Fedora programs are/were compiled), thus breaking the build of many different packages, Ruby included. From the looks of that patch the Ruby developers anticipated NI_MAXHOST being undefined, but flubbed the fixup. Certainly seems like the patch should be upstream to me... -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From uwe at kubosch.no Mon Feb 2 08:33:38 2009 From: uwe at kubosch.no (Uwe Kubosch) Date: Mon, 02 Feb 2009 09:33:38 +0100 Subject: [Fedora-packaging] Stupid question In-Reply-To: <49868E99.3090609@kanarip.com> References: <49868E99.3090609@kanarip.com> Message-ID: <1233563618.5468.9.camel@pippin> On Mon, 2009-02-02 at 07:11 +0100, Jeroen van Meeuwen wrote: > I've taken over the ruby package, which basically is the first > core-component piece of software on my relatively small list of packages. > > Attached is a patch that was in ruby-1.8.6, and that I rebased to > ruby-1.8.7. Since it's a really simple patch, I wonder why it's not > upstream. Please do not move the Ruby 1.8 package to 1.8.7. The consensus in the Ruby community is that 1.8.7 introduces unnecessary incompatibilities without really adding value. 1.8.7 is meant as a transitional package to Ruby 1.9, but the majority of Ruby users will want to keep using Ruby 1.8.6 until they switch directly to Ruby 1.9.1. You should focus on maintaining Ruby 1.8.6 and Ruby 1.9.1 in parallel. Ruby 1.8.7 should be passed over unless there is a very clear demand from Fedora users to introduce it. -- With kind regards, Uwe Kubosch Kubosch Consulting Norway -------------- 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 Feb 2 12:00:01 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 2 Feb 2009 13:00:01 +0100 Subject: [Fedora-packaging] gfortran modules directory owning? Message-ID: <20090202120001.GA12647@free.fr> Hello, Some time ago a guideline for gfortran modules directory was accepted: http://fedoraproject.org/wiki/PackagingDrafts/FortranModulesDir First I think this should be in the guidelines, %_fmoddir is in since F10. Second, there is an issue with directory ownership. The directories in that proposal, for .mod files, are not owned by any package: %_libdir/gfortan %_libdir/gfortan/modules One possibility could be to have libgfortran own them, that way libraries dynamically linked whould bring in libgfortran and the directories. However for libraries linked statically, this doesn't work since they don't depend explicitly on libgortran, but they depend on gcc-gfortran adding the right link information when doing the link. The guideline is not to require the compiler for -devel packages, unless I am missing something. As a side note, since gcc-gfortran is not in the minimal buildroot it has to be a BauildRequires, though. I see 2 possibilities to solve that issue: * put %_libdir/gfortan %_libdir/gfortan/modules in filesystem * do an addition to the guideline PackagingDrafts/FortranModulesDir to have library linked statically by gfortran and installing .mod files have an explicit dependency on gcc-gfortran. What's your opinion? A bugzilla for directory ownership issue: https://bugzilla.redhat.com/show_bug.cgi?id=483469 -- Pat From ivazqueznet at gmail.com Mon Feb 2 12:09:25 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 02 Feb 2009 07:09:25 -0500 Subject: [Fedora-packaging] Stupid question In-Reply-To: <1233563618.5468.9.camel@pippin> References: <49868E99.3090609@kanarip.com> <1233563618.5468.9.camel@pippin> Message-ID: <1233576565.26470.32.camel@ignacio.lan> On Mon, 2009-02-02 at 09:33 +0100, Uwe Kubosch wrote: > On Mon, 2009-02-02 at 07:11 +0100, Jeroen van Meeuwen wrote: > > I've taken over the ruby package, which basically is the first > > core-component piece of software on my relatively small list of packages. > > > > Attached is a patch that was in ruby-1.8.6, and that I rebased to > > ruby-1.8.7. Since it's a really simple patch, I wonder why it's not > > upstream. > > Please do not move the Ruby 1.8 package to 1.8.7. The consensus in the > Ruby community is that 1.8.7 introduces unnecessary incompatibilities > without really adding value. 1.8.7 is meant as a transitional package > to Ruby 1.9, but the majority of Ruby users will want to keep using Ruby > 1.8.6 until they switch directly to Ruby 1.9.1. You should focus on > maintaining Ruby 1.8.6 and Ruby 1.9.1 in parallel. Ruby 1.8.7 should be > passed over unless there is a very clear demand from Fedora users to > introduce it. ... I had something witty-yet-acerbic to respond with, but I think my presence alone in this thread may be enough :P -- 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: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon Feb 2 18:19:04 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Feb 2009 13:19:04 -0500 Subject: [Fedora-packaging] Re: Remove "Encoding=UTF-8" from sample desktop file In-Reply-To: <20090201091803.GC31604@teufli.physik.fu-berlin.de> References: <49848D0C.5030306@fi.muni.cz> <4984A55E.1000602@redhat.com> <20090201091803.GC31604@teufli.physik.fu-berlin.de> Message-ID: <49873918.5070306@redhat.com> On 2009-02-01 at 4:18:03 -0500, Axel Thimm wrote: > Hi, > > On Sat, Jan 31, 2009 at 02:24:14PM -0500, Tom spot Callaway wrote: >> On 2009-01-31 at 12:40:28 -0500, Milos Jakubicek wrote: >>> yesterday when reviewing a package I noticed that although we have a >>> MUST: follow the desktop-entry-spec in the Guidelines, the example on >>> that page includes a line with: >>> >>> Encoding=UTF-8 >>> >>> which is deprecated according to: >>> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#legacy-mixed >>> >>> >>> We should get rid of that line, as some people (including me) are taking >>> that sample as a basis when creating new desktop files, shouldn't we? >> Yep. That line is gone now. > > is that compatible to siblings like RHEL4? That example was ancient, and not chosen because it was a good example, it was merely what was handy at the time (Fedora Core 4 era). RHEL4 is going to have divergence due to its age, we're just going to have to accept it and move on. ~spot From tcallawa at redhat.com Mon Feb 2 18:21:44 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 02 Feb 2009 13:21:44 -0500 Subject: [Fedora-packaging] gfortran modules directory owning? In-Reply-To: <20090202120001.GA12647@free.fr> References: <20090202120001.GA12647@free.fr> Message-ID: <498739B8.60402@redhat.com> On 2009-02-02 at 7:00:01 -0500, Patrice Dumas wrote: > I see 2 possibilities to solve that issue: > * put %_libdir/gfortan %_libdir/gfortan/modules in filesystem > * do an addition to the guideline PackagingDrafts/FortranModulesDir to > have library linked statically by gfortran and installing .mod files > have an explicit dependency on gcc-gfortran. A third possibility would be to permit each package that does not depend on gcc-gfortran to own those directories (and then have gcc-gfortran own them). ~spot From pertusus at free.fr Tue Feb 3 15:00:11 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 3 Feb 2009 16:00:11 +0100 Subject: [Fedora-packaging] gfortran modules directory owning? In-Reply-To: <498739B8.60402@redhat.com> References: <20090202120001.GA12647@free.fr> <498739B8.60402@redhat.com> Message-ID: <20090203150011.GC27818@free.fr> On Mon, Feb 02, 2009 at 01:21:44PM -0500, Tom spot Callaway wrote: > On 2009-02-02 at 7:00:01 -0500, Patrice Dumas wrote: > > I see 2 possibilities to solve that issue: > > * put %_libdir/gfortan %_libdir/gfortan/modules in filesystem > > * do an addition to the guideline PackagingDrafts/FortranModulesDir to > > have library linked statically by gfortran and installing .mod files > > have an explicit dependency on gcc-gfortran. > > A third possibility would be to permit each package that does not depend > on gcc-gfortran to own those directories (and then have gcc-gfortran own > them). Ok. It is better if it is libgfortran and not gcc-gfortran, I filled https://bugzilla.redhat.com/show_bug.cgi?id=483765 -- Pat From kanarip at kanarip.com Tue Feb 3 17:13:42 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 03 Feb 2009 18:13:42 +0100 Subject: [Fedora-packaging] Stupid question In-Reply-To: <1233576565.26470.32.camel@ignacio.lan> References: <49868E99.3090609@kanarip.com> <1233563618.5468.9.camel@pippin> <1233576565.26470.32.camel@ignacio.lan> Message-ID: <49887B46.3040607@kanarip.com> Ignacio Vazquez-Abrams wrote: > On Mon, 2009-02-02 at 09:33 +0100, Uwe Kubosch wrote: >> On Mon, 2009-02-02 at 07:11 +0100, Jeroen van Meeuwen wrote: >>> I've taken over the ruby package, which basically is the first >>> core-component piece of software on my relatively small list of packages. >>> >>> Attached is a patch that was in ruby-1.8.6, and that I rebased to >>> ruby-1.8.7. Since it's a really simple patch, I wonder why it's not >>> upstream. >> Please do not move the Ruby 1.8 package to 1.8.7. The consensus in the >> Ruby community is that 1.8.7 introduces unnecessary incompatibilities >> without really adding value. 1.8.7 is meant as a transitional package >> to Ruby 1.9, but the majority of Ruby users will want to keep using Ruby >> 1.8.6 until they switch directly to Ruby 1.9.1. You should focus on >> maintaining Ruby 1.8.6 and Ruby 1.9.1 in parallel. Ruby 1.8.7 should be >> passed over unless there is a very clear demand from Fedora users to >> introduce it. > > ... > > I had something witty-yet-acerbic to respond with, but I think my > presence alone in this thread may be enough :P > Geh... http://kanarip.livejournal.com/9911.html Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Tue Feb 3 17:14:27 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 03 Feb 2009 18:14:27 +0100 Subject: [Fedora-packaging] Stupid question In-Reply-To: <935ead450902012230g295c3477j267c9bf8a0eade44@mail.gmail.com> References: <49868E99.3090609@kanarip.com> <935ead450902012230g295c3477j267c9bf8a0eade44@mail.gmail.com> Message-ID: <49887B73.2040100@kanarip.com> Jeffrey Ollie wrote: > On Mon, Feb 2, 2009 at 12:11 AM, Jeroen van Meeuwen wrote: >> I've taken over the ruby package, which basically is the first >> core-component piece of software on my relatively small list of packages. >> >> Attached is a patch that was in ruby-1.8.6, and that I rebased to >> ruby-1.8.7. Since it's a really simple patch, I wonder why it's not >> upstream. >> >> I'm not sure what this fixes, in that ruby will build without the patch as >> well. I've searched through the logs to see if there's some kind of warning >> related to socket.c, but there is none from what I can tell. >> >> I'd love to learn what this patch does and then try and get upstream to >> accept it (so that I have less work to do). Can someone on this list help me >> with this? > > For a while back in February of '08 was some breakage in glibc where > NI_MAXHOST wasn't defined anymore (at least not under the usual > circumstances that Fedora programs are/were compiled), thus breaking > the build of many different packages, Ruby included. From the looks > of that patch the Ruby developers anticipated NI_MAXHOST being > undefined, but flubbed the fixup. Certainly seems like the patch > should be upstream to me... > Thanks! It turns out it is upstream already, just not in 1.8.7-p72. I feel confident to ship the patch now ;-) Kind regards, Jeroen van Meeuwen -kanarip From a.badger at gmail.com Tue Feb 3 18:32:16 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 03 Feb 2009 10:32:16 -0800 Subject: [Fedora-packaging] ExplicitRequires/Commenting Drafts Message-ID: <49888DB0.7080202@gmail.com> Hey guys, Since we passed this again with minor changes but one of FESCo's comments seemed to be that they thought the two changes were being proposed as a whole, I'm going to split this into two pages. Explicit Requires will keep the :MUST: and the == Explicit Requires == section. The new, Non-obvious spec file items will have the :Should: and == Non-Obvious Items in Spec Files == section. The text of both sections will remain unchanged. (spot has already updated for the FHS removal). Holler at me if you think this violates our rules. -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 nicolas.mailhot at laposte.net Wed Feb 4 21:48:57 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 04 Feb 2009 22:48:57 +0100 Subject: [Fedora-packaging] Re: Too many unowned directories In-Reply-To: <9daafa4ead59ed4dbeca1c8791f6e12d.squirrel@arekh.dyndns.org> References: <20090130200118.dcf06aa3.mschwendt@gmail.com> <20090131111130.GA23533@amd.home.annexia.org> <20090131134347.7bb42020.mschwendt@gmail.com> <20090131193421.GA24526@amd.home.annexia.org> <49858A57.8060406@redhat.com> <4986B059.30108@hhs.nl> <20090202100801.96522807.mschwendt@gmail.com> <9daafa4ead59ed4dbeca1c8791f6e12d.squirrel@arekh.dyndns.org> Message-ID: <1233784137.18874.14.camel@arekh.okg> Just to be clear: the directory ownership page says something like "if you have multiple packages that use the same directory and do not depend on a common package that owns it they can all own this directory in parallel". But with fonts we have cases where 1. the common package exists for other reasons, or 2 it's only there to own the common directory. In case 2. the guidelines clearly allow dropping common and using multiple ownership. My problem is case 1.: is it ok for each subpackage to own the directory it installs fonts to, even though it depends on a common package that already owns it for other reasons (for example, to put core fonts indexes in it)? Because making the font subpackage macro auto-own the font dir in all cases is trivial, would simplify the templates and avoid packaging errors, but detecting the presence of a common subpackage to avoid the auto-owning in that case is *not* trivial at all. NB: in all this discussion the "common" subpackage is created from the same srpm and never shared with subpackages from another srpm -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Thu Feb 5 21:08:54 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 5 Feb 2009 23:08:54 +0200 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (=?iso-8859-1?q?icon=09cache?=) changes In-Reply-To: <200901282148.35660.ville.skytta@iki.fi> References: <200901280136.37005.ville.skytta@iki.fi> <4980A9C4.6000902@math.unl.edu> <200901282148.35660.ville.skytta@iki.fi> Message-ID: <200902052308.55347.ville.skytta@iki.fi> Hello, So I gather as the result of this discussion would be: ---- %post touch --no-create %{_datadir}/icons/hicolor &>/dev/null || : %postun if [ $1 -eq 0 ] ; then touch --no-create %{_datadir}/icons/hicolor &>/dev/null gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : fi %posttrans gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : ---- Initial install and upgrades are handled by %post and %posttrans, final erase by %postun. Anything more to tweak? If not, is this discussion (see also 1) in my initial mail [0]) and summary enough for the FPC so you can look into it in a near future meeting? [0] https://www.redhat.com/archives/fedora-packaging/2009-January/msg00138.html From henriquecsj at gmail.com Fri Feb 6 12:24:45 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Fri, 6 Feb 2009 10:24:45 -0200 Subject: [Fedora-packaging] Reviewer needed Message-ID: <4f629b520902060424ua5d63abn94eedb0aace3a913@mail.gmail.com> Hello, everybody, I need a benevolent reviewer for this package [1]. Could someone help me? pdumpfs is a simple daily backup system similar to Plan9's dumpfs which > preserves every daily snapshot. pdumpfs is written in Ruby. You can > access the past snapshots at any time for retrieving a certain day's > file. Let's backup your home directory with pdumpfs! > > [1] - https://bugzilla.redhat.com/show_bug.cgi?id=480857 Thanks -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirantpatil at gmail.com Mon Feb 9 08:07:02 2009 From: kirantpatil at gmail.com (Kiran Patil) Date: Mon, 9 Feb 2009 13:37:02 +0530 Subject: [Fedora-packaging] Aperi Storage Management Project for Fedora Message-ID: Hello Friends, Are you planning to package "Aperi Storage Management Project" in Fedora ? Project website: http://www.eclipse.org/aperi/ Let me know, how can I help in this regard. -- Kind Regards, --------------------------------------- Kiran T Patil (Director) Green Turtles Technologies direct: +91-80-41728133 www.greenturtles.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From hlk.dogan at gmail.com Mon Feb 9 12:29:31 2009 From: hlk.dogan at gmail.com (Haluk Dogan) Date: Mon, 9 Feb 2009 13:29:31 +0100 Subject: [Fedora-packaging] awesome tiling window manager Message-ID: <575b75130902090429o3e2ba05fxa9fe0adb81895335@mail.gmail.com> Hi, I was trying to build awesome for few days, unfortunately I got several errors. When I looked its official web site, they made a package for many linux distribution except fedora. I wonder that would someone able to make an rpm package and put it to repository? Many thanks in advance. Regards Haluk --- HD -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Mon Feb 9 12:34:30 2009 From: paul at city-fan.org (Paul Howarth) Date: Mon, 09 Feb 2009 12:34:30 +0000 Subject: [Fedora-packaging] awesome tiling window manager In-Reply-To: <575b75130902090429o3e2ba05fxa9fe0adb81895335@mail.gmail.com> References: <575b75130902090429o3e2ba05fxa9fe0adb81895335@mail.gmail.com> Message-ID: <499022D6.1040009@city-fan.org> Haluk Dogan wrote: > Hi, > > I was trying to build awesome for few days, unfortunately I got several > errors. When I looked its official web site, they made a package for > many linux distribution except fedora. I wonder that would someone able > to make an rpm package and put it to repository? Many thanks in advance. > > Regards Haluk A package has already been submitted for inclusion in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=452427 Paul. From rdieter at math.unl.edu Mon Feb 9 12:38:25 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Feb 2009 06:38:25 -0600 Subject: [Fedora-packaging] awesome tiling window manager In-Reply-To: <575b75130902090429o3e2ba05fxa9fe0adb81895335@mail.gmail.com> References: <575b75130902090429o3e2ba05fxa9fe0adb81895335@mail.gmail.com> Message-ID: <499023C1.6090605@math.unl.edu> Haluk Dogan wrote: > I was trying to build awesome for few days, unfortunately I got several > errors. When I looked its official web site, they made a package for > many linux distribution except fedora. I wonder that would someone able > to make an rpm package and put it to repository? Many thanks in advance Currently pending review: https://bugzilla.redhat.com/show_bug.cgi?id=awesome -- Rex From michel.sylvan at gmail.com Mon Feb 9 13:19:34 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 09 Feb 2009 08:19:34 -0500 Subject: [Fedora-packaging] Rawhide's Mono stack Message-ID: <49902D66.8010100@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Fedora Mono developers, (ps if you are not in http://fedoraproject.org/wiki/SIGs/Mono, I get your name from the changelog of relevant *-sharp packages; please consider adding your name) The current Mono stack in post-alpha Rawhide is rather broken -- as of today, on my machine (x86_64) none of these packages work: - - monodevelop - - banshee - - tomboy - - f-spot It seems that the entire stack of libraries need to be recompiled -- gtk-sharp2, etc., and as such we should probably coordinate the rebuilding process. If B depends on A, does a rebuild of A affect B with Mono packages? Not so sure about this; if not, it makes life easier. If there are dependencies, then one way I could suggest is that we all commit updated specs, and then someone (Paul?) could do a chain build of all the packages. Another item: as I proposed in -devel recently, we could probably get more Infrastructure support. - - our own disttag, similar to the one for the gcc44 test rebuilds earlier - - that would probably require our own mailing list, to coordinate matters like this Thoughts? Suggestions? Thanks in advance, - -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmQLWYACgkQWt0J3fd+7ZCnZgCdFCbgxeipw/BiW6zzyt1k8Do4 mXAAnjXi9gPVJziqPakbU8uLcKUsMCCN =UBGD -----END PGP SIGNATURE----- From xjakub at fi.muni.cz Mon Feb 9 14:42:34 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Mon, 09 Feb 2009 15:42:34 +0100 Subject: [Fedora-packaging] awesome tiling window manager In-Reply-To: <499023C1.6090605@math.unl.edu> References: <575b75130902090429o3e2ba05fxa9fe0adb81895335@mail.gmail.com> <499023C1.6090605@math.unl.edu> Message-ID: <499040DA.9030001@fi.muni.cz> Rex Dieter wrote: > Haluk Dogan wrote: > >> I was trying to build awesome for few days, unfortunately I got >> several errors. When I looked its official web site, they made a >> package for many linux distribution except fedora. I wonder that would >> someone able to make an rpm package and put it to repository? Many >> thanks in advance > > Currently pending review: > https://bugzilla.redhat.com/show_bug.cgi?id=awesome Unfortunately the review is not going to be closed in the near future as current cairo maintainers are not willing to build cairo with xcb support (it is still not officially supported, though...), see: https://bugzilla.redhat.com/show_bug.cgi?id=465759 -- Regards, Milos Jakubicek From rjones at redhat.com Mon Feb 9 15:33:42 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 9 Feb 2009 15:33:42 +0000 Subject: [Fedora-packaging] Vala packaging guidelines - are there any? Message-ID: <20090209153342.GA4376@amd.home.annexia.org> Do we have packaging guidelines applicable for the Vala programming language? I've reviewed a couple of packages now and they don't have a consistent naming convention. eg: vala - the base package emacs-vala - emacs mode gupnp-vala - vala bindings for gupnp (universal plug'n'play) library vtg - "Vala Toys for gEdit" currently under review here: https://bugzilla.redhat.com/show_bug.cgi?id=484360 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From a.badger at gmail.com Mon Feb 9 17:48:32 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Feb 2009 09:48:32 -0800 Subject: [Fedora-packaging] Vala packaging guidelines - are there any? In-Reply-To: <20090209153342.GA4376@amd.home.annexia.org> References: <20090209153342.GA4376@amd.home.annexia.org> Message-ID: <49906C70.60003@gmail.com> Richard W.M. Jones wrote: > Do we have packaging guidelines applicable for the Vala programming > language? I've reviewed a couple of packages now and they don't have > a consistent naming convention. > > eg: > I think our generic naming guidelines[1]_ would recommend: > vala - the base package > Fine. > emacs-vala - emacs mode > Fine. This is an addon to emace. > gupnp-vala - vala bindings for gupnp (universal plug'n'play) library > vala-gupnp. These are an "addon" to vala. > vtg - "Vala Toys for gEdit" currently under review here: > https://bugzilla.redhat.com/show_bug.cgi?id=484360 > gedit-vtg. This is an addon to gedit. .. _[1]: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28General.29 If you think the generic guidelines don't apply or don't suggest the correct thing, feel free to propose an addition. -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 eric.tanguy at univ-nantes.fr Mon Feb 9 21:19:16 2009 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Mon, 09 Feb 2009 22:19:16 +0100 Subject: [Fedora-packaging] MimeType error in desktop file Message-ID: <49909DD4.8020407@univ-nantes.fr> Building a package for rawhide i obtain this error : /builddir/build/BUILDROOT/scidavis-0.1.4-1.fc11.i386/usr/share/applications/fedora-scidavis.desktop: error: value "application/x-sciprj;;" for key "MimeType" in group "Desktop Entry" contains value "" which does not look like a MIME type Someone could explain where the problem come from and how to solve it ? Thanks Eric From rdieter at math.unl.edu Mon Feb 9 21:43:13 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Feb 2009 15:43:13 -0600 Subject: [Fedora-packaging] MimeType error in desktop file In-Reply-To: <49909DD4.8020407@univ-nantes.fr> References: <49909DD4.8020407@univ-nantes.fr> Message-ID: <4990A371.5010703@math.unl.edu> Eric Tanguy wrote: > Building a package for rawhide i obtain this error : > /builddir/build/BUILDROOT/scidavis-0.1.4-1.fc11.i386/usr/share/applications/fedora-scidavis.desktop: > error: value "application/x-sciprj;;" for key "MimeType" in group > "Desktop Entry" contains value "" which does not look like a MIME type > Someone could explain where the problem come from and how to solve it ? Looks like it has MimeType=application/x-sciprj;; which is one too many semi colons. -- Rex From paul at all-the-johnsons.co.uk Mon Feb 9 22:18:48 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 09 Feb 2009 22:18:48 +0000 Subject: [Fedora-packaging] Re: Rawhide's Mono stack In-Reply-To: <49902D66.8010100@gmail.com> References: <49902D66.8010100@gmail.com> Message-ID: <1234217928.6740.99.camel@PB3.Linux> Hi, > The current Mono stack in post-alpha Rawhide is rather broken -- as of > today, on my machine (x86_64) none of these packages work: > - - monodevelop > - - banshee > - - tomboy > - - f-spot I know the last 3 need a rebuild as they're built using mono-addins-0.3. What problems are you seeing with MD? It's working happily here. > It seems that the entire stack of libraries need to be recompiled -- > gtk-sharp2, etc., and as such we should probably coordinate the > rebuilding process. If B depends on A, does a rebuild of A affect B with > Mono packages? Not so sure about this; if not, it makes life easier. It depends (sorry). Mono itself doesn't typically need anything for a rebuild. However, if something is built against mono-tools or mono-addins (such as MD and f-spot), then these will break. I've not noticed anything big break with gtk-sharp2 or gnome-sharp. AFAIK, the only one with a really nasty circular dependency problem is nant with mono-cecil-flowanalysis. The move to the 2.4 pre-releases should not be causing any significant problems. > If there are dependencies, then one way I could suggest is that we all > commit updated specs, and then someone (Paul?) could do a chain build of > all the packages. I'm fine for that :-) > Another item: as I proposed in -devel recently, we could probably get > more Infrastructure support. > - - our own disttag, similar to the one for the gcc44 test rebuilds earlier > - - that would probably require our own mailing list, to coordinate > matters like this This would make a lot of sense and would also make the version numbering a hell of a lot simpler TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 michel.sylvan at gmail.com Tue Feb 10 03:16:07 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 9 Feb 2009 22:16:07 -0500 Subject: [Fedora-packaging] Re: Rawhide's Mono stack In-Reply-To: <1234217928.6740.99.camel@PB3.Linux> References: <49902D66.8010100@gmail.com> <1234217928.6740.99.camel@PB3.Linux> Message-ID: On Mon, Feb 9, 2009 at 5:18 PM, Paul wrote: > Hi, > >> The current Mono stack in post-alpha Rawhide is rather broken -- as of >> today, on my machine (x86_64) none of these packages work: >> - - monodevelop >> - - banshee >> - - tomboy >> - - f-spot > > I know the last 3 need a rebuild as they're built using mono-addins-0.3. > What problems are you seeing with MD? It's working happily here. Bizarre, after a restart, it works too. I'm pretty sure it was not working this morning, right after an update. Log files for Banshee and Tomboy attached. Any idea? >> It seems that the entire stack of libraries need to be recompiled -- >> gtk-sharp2, etc., and as such we should probably coordinate the >> rebuilding process. If B depends on A, does a rebuild of A affect B with >> Mono packages? Not so sure about this; if not, it makes life easier. > > It depends (sorry). Mono itself doesn't typically need anything for a > rebuild. However, if something is built against mono-tools or > mono-addins (such as MD and f-spot), then these will break. I've not > noticed anything big break with gtk-sharp2 or gnome-sharp. Ah, ok. but if, say, gtk-sharp2 needs to be rebuilt, would a Mono package that depends on it need to be rebuilt, if the version number stays the same? i.e. do we have a C situation, or a C++ situation where the ABI of DLLs might change with compiler version. >> If there are dependencies, then one way I could suggest is that we all >> commit updated specs, and then someone (Paul?) could do a chain build of >> all the packages. > > I'm fine for that :-) > >> Another item: as I proposed in -devel recently, we could probably get >> more Infrastructure support. >> - - our own disttag, similar to the one for the gcc44 test rebuilds earlier >> - - that would probably require our own mailing list, to coordinate >> matters like this > > This would make a lot of sense and would also make the version numbering > a hell of a lot simpler > With the guideline in mind, how about using 0.x.DATEsvnREV until the package is stable, and then switching to normal revision numbers? I'm still unable to run banshee and tomboy -- after the rebuild. The exceptions thrown do not really make any sense. I'm attaching them, hopefully someone can make some sense out of them. Anyone else experiencing problems? Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org -------------- next part -------------- [Info 22:08:32.874] Running Banshee 1.4.2: [source-tarball (linux-gnu, x86_64) @ 2009-02-07 23:06:15 EST] [Warn 22:08:34.682] Service `Nereid.PlayerInterface' not started: An exception was thrown by the type initializer for Hyena.Gui.RatingRenderer [Warn 22:08:34.684] Caught an exception - Number overflow. (in `Hyena.Gui') at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_2 (intptr,intptr,intptr) at Hyena.Gui.RatingRenderer..cctor () [0x00000] An exception was thrown by the type initializer for Hyena.Gui.RatingRenderer (in `Hyena.Gui') at Hyena.Data.Gui.ColumnCellRating..ctor (System.String property, Boolean expand) [0x00000] at Banshee.Collection.Gui.DefaultColumnController.CreateDefaultColumns () [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor (Boolean loadDefault) [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor () [0x00000] at Banshee.Collection.Gui.TrackListView..ctor () [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents.InitializeViews () [0x00000] at Banshee.Sources.Gui.FilteredListSourceContents..ctor (System.String name) [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents..ctor () [0x00000] at Nereid.PlayerInterface.BuildViews () [0x00000] at Nereid.PlayerInterface.BuildPrimaryLayout () [0x00000] at Nereid.PlayerInterface.Initialize () [0x00000] at Banshee.Gui.BaseClientWindow.InitializeWindow () [0x00000] at Banshee.Gui.BaseClientWindow..ctor (System.String title, System.String configNameSpace, Int32 defaultWidth, Int32 defaultHeight) [0x00000] at Nereid.PlayerInterface..ctor () [0x00000] at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] [Warn 22:08:34.766] Caught an exception - Number overflow. (in `Hyena.Gui') at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_2 (intptr,intptr,intptr) at Hyena.Gui.RatingRenderer..cctor () [0x00000] [Warn 22:08:34.766] Extension `Banshee.NotificationArea.NotificationAreaService' not started: An exception was thrown by the type initializer for Hyena.Gui.RatingRenderer [Warn 22:08:35.044] Caught an exception - Number overflow. (in `Hyena.Gui') at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_2 (intptr,intptr,intptr) at Hyena.Gui.RatingRenderer..cctor () [0x00000] An exception was thrown by the type initializer for Hyena.Gui.RatingRenderer (in `Hyena.Gui') at Hyena.Data.Gui.ColumnCellRating..ctor (System.String property, Boolean expand) [0x00000] at Banshee.Collection.Gui.DefaultColumnController.CreateDefaultColumns () [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor (Boolean loadDefault) [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor () [0x00000] at Banshee.Collection.Gui.TrackListView..ctor () [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents.InitializeViews () [0x00000] at Banshee.Sources.Gui.FilteredListSourceContents..ctor (System.String name) [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents..ctor () [0x00000] at Nereid.PlayerInterface.BuildViews () [0x00000] at Nereid.PlayerInterface.BuildPrimaryLayout () [0x00000] at Nereid.PlayerInterface.Initialize () [0x00000] at Banshee.Gui.BaseClientWindow.InitializeWindow () [0x00000] at Banshee.Gui.BaseClientWindow..ctor (System.String title, System.String configNameSpace, Int32 defaultWidth, Int32 defaultHeight) [0x00000] at Nereid.PlayerInterface..ctor () [0x00000] at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] [Warn 22:08:35.044] Extension `/Banshee/ServiceManager/Service/__nid_9' not started: Exception has been thrown by the target of an invocation. (Banshee:5751): Gtk-WARNING **: Refusing to add non-unique action 'CloseAction' to action group 'Global' [Warn 22:08:35.334] Caught an exception - Group already exists (in `Banshee.ThickClient') at Banshee.Gui.InterfaceActionService.AddActionGroup (Gtk.ActionGroup group) [0x00000] at Banshee.NotificationArea.NotificationAreaService.Initialize () [0x00000] at Banshee.NotificationArea.NotificationAreaService.ServiceStartup () [0x00000] at Banshee.NotificationArea.NotificationAreaService.Banshee.ServiceStack.IExtensionService.Initialize () [0x00000] at Banshee.ServiceStack.ServiceManager.StartExtension (Mono.Addins.TypeExtensionNode node) [0x00000] [Warn 22:08:35.335] Extension `Banshee.NotificationArea.NotificationAreaService' not started: Group already exists [Warn 22:08:35.345] Caught an exception - Number overflow. (in `Hyena.Gui') at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_2 (intptr,intptr,intptr) at Hyena.Gui.RatingRenderer..cctor () [0x00000] An exception was thrown by the type initializer for Hyena.Gui.RatingRenderer (in `Hyena.Gui') at Hyena.Data.Gui.ColumnCellRating..ctor (System.String property, Boolean expand) [0x00000] at Banshee.Collection.Gui.DefaultColumnController.CreateDefaultColumns () [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor (Boolean loadDefault) [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor () [0x00000] at Banshee.Collection.Gui.TrackListView..ctor () [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents.InitializeViews () [0x00000] at Banshee.Sources.Gui.FilteredListSourceContents..ctor (System.String name) [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents..ctor () [0x00000] at Nereid.PlayerInterface.BuildViews () [0x00000] at Nereid.PlayerInterface.BuildPrimaryLayout () [0x00000] at Nereid.PlayerInterface.Initialize () [0x00000] at Banshee.Gui.BaseClientWindow.InitializeWindow () [0x00000] at Banshee.Gui.BaseClientWindow..ctor (System.String title, System.String configNameSpace, Int32 defaultWidth, Int32 defaultHeight) [0x00000] at Nereid.PlayerInterface..ctor () [0x00000] at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] [Warn 22:08:35.345] Extension `/Banshee/ServiceManager/Service/__nid_9' not started: Exception has been thrown by the target of an invocation. [Info 22:08:35.346] All services are started 2.073419s System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: An exception was thrown by the type initializer for Hyena.Gui.RatingRenderer ---> System.OverflowException: Number overflow. at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_2 (intptr,intptr,intptr) at Hyena.Gui.RatingRenderer..cctor () [0x00000] --- End of inner exception stack trace --- at Hyena.Data.Gui.ColumnCellRating..ctor (System.String property, Boolean expand) [0x00000] at Banshee.Collection.Gui.DefaultColumnController.CreateDefaultColumns () [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor (Boolean loadDefault) [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor () [0x00000] at Banshee.Collection.Gui.TrackListView..ctor () [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents.InitializeViews () [0x00000] at Banshee.Sources.Gui.FilteredListSourceContents..ctor (System.String name) [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents..ctor () [0x00000] at Nereid.PlayerInterface.BuildViews () [0x00000] at Nereid.PlayerInterface.BuildPrimaryLayout () [0x00000] at Nereid.PlayerInterface.Initialize () [0x00000] at Banshee.Gui.BaseClientWindow.InitializeWindow () [0x00000] at Banshee.Gui.BaseClientWindow..ctor (System.String title, System.String configNameSpace, Int32 defaultWidth, Int32 defaultHeight) [0x00000] at Nereid.PlayerInterface..ctor () [0x00000] at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] --- End of inner exception stack trace --- at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000] at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] at System.Activator.CreateInstance (System.Type type) [0x00000] at Mono.Addins.TypeExtensionNode.CreateInstance () [0x00000] at Banshee.Sources.SourceManager.OnExtensionChanged (System.Object o, Mono.Addins.ExtensionNodeEventArgs args) [0x00000] at Mono.Addins.ExtensionNode.add_ExtensionNodeChanged (Mono.Addins.ExtensionNodeEventHandler value) [0x00000] System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeInitializationException: An exception was thrown by the type initializer for Hyena.Gui.RatingRenderer ---> System.OverflowException: Number overflow. at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_2 (intptr,intptr,intptr) at Hyena.Gui.RatingRenderer..cctor () [0x00000] --- End of inner exception stack trace --- at Hyena.Data.Gui.ColumnCellRating..ctor (System.String property, Boolean expand) [0x00000] at Banshee.Collection.Gui.DefaultColumnController.CreateDefaultColumns () [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor (Boolean loadDefault) [0x00000] at Banshee.Collection.Gui.DefaultColumnController..ctor () [0x00000] at Banshee.Collection.Gui.TrackListView..ctor () [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents.InitializeViews () [0x00000] at Banshee.Sources.Gui.FilteredListSourceContents..ctor (System.String name) [0x00000] at Banshee.Sources.Gui.CompositeTrackSourceContents..ctor () [0x00000] at Nereid.PlayerInterface.BuildViews () [0x00000] at Nereid.PlayerInterface.BuildPrimaryLayout () [0x00000] at Nereid.PlayerInterface.Initialize () [0x00000] at Banshee.Gui.BaseClientWindow.InitializeWindow () [0x00000] at Banshee.Gui.BaseClientWindow..ctor (System.String title, System.String configNameSpace, Int32 defaultWidth, Int32 defaultHeight) [0x00000] at Nereid.PlayerInterface..ctor () [0x00000] at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] --- End of inner exception stack trace --- at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MonoCMethod.Invoke (BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) [0x00000] at System.Activator.CreateInstance (System.Type type, Boolean nonPublic) [0x00000] at System.Activator.CreateInstance (System.Type type) [0x00000] at Mono.Addins.TypeExtensionNode.CreateInstance () [0x00000] at Banshee.Sources.SourceManager.OnExtensionChanged (System.Object o, Mono.Addins.ExtensionNodeEventArgs args) [0x00000] at Mono.Addins.ExtensionNode.add_ExtensionNodeChanged (Mono.Addins.ExtensionNodeEventHandler value) [0x00000] (Banshee:5751): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed [Info 22:08:36.028] nereid Client Started -------------- next part -------------- [DEBUG]: NoteManager created with note path "/home/michel/.tomboy". [INFO]: Initializing Mono.Addins [DEBUG]: AddinManager.OnAddinLoaded: Tomboy.Tomboy [DEBUG]: Name: Tomboy.Tomboy,0.10 [DEBUG]: Description: [DEBUG]: Namespace: Tomboy [DEBUG]: Enabled: True [DEBUG]: File: /usr/lib64/tomboy/Tomboy.exe [WARN]: Error initializing addin: Tomboy.NoteWikiWatcher: An exception was thrown by the type initializer for Tomboy.Contrast [WARN]: Error initializing addin: Tomboy.NoteRenameWatcher: An exception was thrown by the type initializer for Tomboy.Contrast [WARN]: Error initializing addin: Tomboy.NoteLinkWatcher: An exception was thrown by the type initializer for Tomboy.Contrast [WARN]: Error initializing addin: Tomboy.NoteUrlWatcher: An exception was thrown by the type initializer for Tomboy.Contrast [DEBUG]: AddinManager.OnAddinLoaded: Tomboy.ExportToHtmlAddin [DEBUG]: Name: Export to HTML [DEBUG]: Description: Exports individual notes to HTML. [DEBUG]: Namespace: Tomboy [DEBUG]: Enabled: True [DEBUG]: File: /usr/lib64/tomboy/addins/ExportToHtml.dll [DEBUG]: AddinManager.OnAddinLoaded: Tomboy.PrintNotesAddin [DEBUG]: Name: Printing Support [DEBUG]: Description: Allows you to print a note. [DEBUG]: Namespace: Tomboy [DEBUG]: Enabled: True [DEBUG]: File: /usr/lib64/tomboy/addins/PrintNotes.dll [DEBUG]: AddinManager.OnAddinLoaded: Tomboy.BacklinksAddin [DEBUG]: Name: Backlinks [DEBUG]: Description: See which notes link to the one you're currently viewing. [DEBUG]: Namespace: Tomboy [DEBUG]: Enabled: True [DEBUG]: File: /usr/lib64/tomboy/addins/Backlinks.dll [DEBUG]: AddinManager.OnAddinLoaded: Tomboy.FixedWidthAddin [DEBUG]: Name: Fixed Width [DEBUG]: Description: Adds fixed-width font style. [DEBUG]: Namespace: Tomboy [DEBUG]: Enabled: True [DEBUG]: File: /usr/lib64/tomboy/addins/FixedWidth.dll [WARN]: Error initializing addin: Tomboy.FixedWidth.FixedWidthNoteAddin: An exception was thrown by the type initializer for Tomboy.Contrast [DEBUG]: AddinManager.OnAddinLoaded: Tomboy.StickyNoteImportAddin [DEBUG]: Name: Sticky Notes Importer [DEBUG]: Description: Import your notes from the Sticky Notes applet. [DEBUG]: Namespace: Tomboy [DEBUG]: Enabled: True [DEBUG]: File: /usr/lib64/tomboy/addins/StickyNoteImport.dll [DEBUG]: StickyNoteImporter: Sticky Notes XML file does not exist or is invalid! [DEBUG]: Creating Buffer for 'New Note 208'... Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Tomboy.Contrast ---> System.OverflowException: Number overflow. at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_2 (intptr,intptr,intptr) at Tomboy.Contrast..cctor () [0x00000] --- End of inner exception stack trace --- at Tomboy.NoteTag.render_foreground (ContrastPaletteColor symbol) [0x00000] at Tomboy.NoteTag.set_PaletteForeground (ContrastPaletteColor value) [0x00000] at Tomboy.NoteTagTable.InitCommonTags () [0x00000] at Tomboy.NoteTagTable..ctor () [0x00000] at Tomboy.NoteTagTable.get_Instance () [0x00000] at Tomboy.Note.get_TagTable () [0x00000] at Tomboy.NoteWikiWatcher.Initialize () [0x00000] at Tomboy.NoteAddin.Initialize (Tomboy.Note note) [0x00000] at Tomboy.AddinManager.AttachAddin (System.String ext_node_id, Tomboy.Note note, Tomboy.NoteAddin addin) [0x00000] From paul at all-the-johnsons.co.uk Tue Feb 10 23:06:22 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 10 Feb 2009 23:06:22 +0000 Subject: [Fedora-packaging] Re: Rawhide's Mono stack In-Reply-To: References: <49902D66.8010100@gmail.com> <1234217928.6740.99.camel@PB3.Linux> Message-ID: <1234307182.6740.106.camel@PB3.Linux> Hi, > > I know the last 3 need a rebuild as they're built using mono-addins-0.3. > > What problems are you seeing with MD? It's working happily here. > Bizarre, after a restart, it works too. I'm pretty sure it was not > working this morning, right after an update. > > Log files for Banshee and Tomboy attached. Any idea? It looks likely that the big arrays code is causing some sort of problem (it is the only difference between the x86 and x86_64 build and both f-spot and tomboy are running fine here). > >> It seems that the entire stack of libraries need to be recompiled -- > >> gtk-sharp2, etc., and as such we should probably coordinate the > >> rebuilding process. If B depends on A, does a rebuild of A affect B with > >> Mono packages? Not so sure about this; if not, it makes life easier. > > > > It depends (sorry). Mono itself doesn't typically need anything for a > > rebuild. However, if something is built against mono-tools or > > mono-addins (such as MD and f-spot), then these will break. I've not > > noticed anything big break with gtk-sharp2 or gnome-sharp. > > Ah, ok. but if, say, gtk-sharp2 needs to be rebuilt, would a Mono > package that depends on it need to be rebuilt, if the version number > stays the same? i.e. do we have a C situation, or a C++ situation > where the ABI of DLLs might change with compiler version. It shouldn't, unless something big gets changed (it's the same as if you update gtk itself, unless the ABI is changed then recompiling is not always required). The only thing which may cause a problem is if gtk-sharp2 (say) is looking for something in particular from Mono and it's not there. Then gtk-sharp2 will need a rebuild, but if it's only a rebuild anything reliant shouldn't be broken. > >> Another item: as I proposed in -devel recently, we could probably get > >> more Infrastructure support. > >> - - our own disttag, similar to the one for the gcc44 test rebuilds earlier > >> - - that would probably require our own mailing list, to coordinate > >> matters like this > > > > This would make a lot of sense and would also make the version numbering > > a hell of a lot simpler > > > With the guideline in mind, how about using 0.x.DATEsvnREV until the > package is stable, and then switching to normal revision numbers? I'm following the way it's done for mono-cecil-flowanalysis and xmms which has it REVsvnDATE. If I swap to DATEsvnREV, won't that cause a problem or would I just up x by 1 and that solves any issues? > I'm still unable to run banshee and tomboy -- after the rebuild. The > exceptions thrown do not really make any sense. I'm attaching them, > hopefully someone can make some sense out of them. Anyone else > experiencing problems? I'm going to build and commit mono, mono-tools, monodevelop, f-spot and tomboy tonight (UK time - should hit rawhide tomorrow) and remove the big arrays. If the problem continues, let me know. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 Tue Feb 10 23:25:11 2009 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Feb 2009 15:25:11 -0800 Subject: [Fedora-packaging] Re: Rawhide's Mono stack In-Reply-To: <1234307182.6740.106.camel@PB3.Linux> References: <49902D66.8010100@gmail.com> <1234217928.6740.99.camel@PB3.Linux> <1234307182.6740.106.camel@PB3.Linux> Message-ID: <1234308311.28625.6.camel@localhost.localdomain> On Tue, 2009-02-10 at 23:06 +0000, Paul wrote: > I'm following the way it's done for mono-cecil-flowanalysis and xmms > which has it REVsvnDATE. If I swap to DATEsvnREV, won't that cause a > problem or would I just up x by 1 and that solves any issues? Just always bump x, that's what it is there for. Not every scm has a linear increasing revision number. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 mschwendt at gmail.com Thu Feb 12 13:58:10 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 12 Feb 2009 14:58:10 +0100 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification Message-ID: <20090212145810.bce82ec8.mschwendt@gmail.com> > http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles: > > A Fedora package must not contain any duplicate files in the %files > listing. What exactly does that refer to? Only the rpmbuild "warning: File listed twice ..."? Or actual files included in multiple %files sections for (sub-)packages? The latter is not detected by rpmbuild. From a.badger at gmail.com Fri Feb 13 18:14:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Feb 2009 10:14:37 -0800 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <20090212145810.bce82ec8.mschwendt@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> Message-ID: <4995B88D.8060401@gmail.com> Michael Schwendt wrote: >> http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles: >> >> A Fedora package must not contain any duplicate files in the %files >> listing. > > What exactly does that refer to? > > Only the rpmbuild "warning: File listed twice ..."? > Or actual files included in multiple %files sections for (sub-)packages? > > The latter is not detected by rpmbuild. > I'm not quite sure of the scope of the question or of the answer. My interpretation is that this is for a single file listed in the %file(s) section of a package and its sub-packages more than once. Files duplicated between distinct SRPM's would be part of the Conflicts Guideline instead. -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 mschwendt at gmail.com Fri Feb 13 19:46:34 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 13 Feb 2009 20:46:34 +0100 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <4995B88D.8060401@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <4995B88D.8060401@gmail.com> Message-ID: <20090213204634.68eb2ae0.mschwendt@gmail.com> On Fri, 13 Feb 2009 10:14:37 -0800, Toshio wrote: > >> http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles: > >> > >> A Fedora package must not contain any duplicate files in the %files > >> listing. > > > > What exactly does that refer to? > > > > Only the rpmbuild "warning: File listed twice ..."? > > Or actual files included in multiple %files sections for (sub-)packages? > > > > The latter is not detected by rpmbuild. > > > I'm not quite sure of the scope of the question or of the answer. Let me rephrase then for another try: What are packagers and reviewers supposed to check in order to satisfy above guideline? rpmbuild prints a warning for files/dirs which are listed more than once in _the same_ %files section. However, rpmbuild does not notice if files/dirs are listed _in multiple_ %files sections. Not even %doc files. Conclusively, only paying attention to rpmbuild's warnings is easy (a SHOULD guideline would suffice), but doesn't yield much. It only helps with subsequent packaging mistakes (such as moving one %files entry to another subpackage while keeping the duplicated entry in the old package). That does not cover the worse case, i.e. because files duplicated in multiple %files sections are not detected by rpmbuild => the reviewer must examine package contents (with rpmls e.g.) manually. [There's even a third case: Programs that load and display documentation files. Then, files included via %doc are also installed and expected in different directories. Packager should not simply remove duplicated files without verifying that the documentation can still be displayed from within the program.] > My interpretation is that this is for a single file listed in the %file(s) > section of a package and its sub-packages more than once. That would be both cases I cover above. Any suggestion for a better wording of the current guideline? In particular, it refers to "the %files listing" (singular!) and not all %files listings [including subpackages]. > Files duplicated between distinct SRPM's would be part of the Conflicts > Guideline instead. Yes, that's something else. From a.badger at gmail.com Fri Feb 13 22:04:32 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Feb 2009 14:04:32 -0800 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <20090213204634.68eb2ae0.mschwendt@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <4995B88D.8060401@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> Message-ID: <4995EE70.6030805@gmail.com> Michael Schwendt wrote: > On Fri, 13 Feb 2009 10:14:37 -0800, Toshio wrote: > >>>> http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles: >>>> >>>> A Fedora package must not contain any duplicate files in the %files >>>> listing. >>> What exactly does that refer to? >>> >>> Only the rpmbuild "warning: File listed twice ..."? >>> Or actual files included in multiple %files sections for (sub-)packages? >>> >>> The latter is not detected by rpmbuild. >>> >> I'm not quite sure of the scope of the question or of the answer. > > Let me rephrase then for another try: > > What are packagers and reviewers supposed to check in order to satisfy > above guideline? > > > rpmbuild prints a warning for files/dirs which are listed more than once > in _the same_ %files section. > > However, rpmbuild does not notice if files/dirs are listed _in multiple_ > %files sections. Not even %doc files. > > > Conclusively, only paying attention to rpmbuild's warnings is easy (a > SHOULD guideline would suffice), but doesn't yield much. It only helps > with subsequent packaging mistakes (such as moving one %files entry to > another subpackage while keeping the duplicated entry in the old package). > > That does not cover the worse case, i.e. because files duplicated in > multiple %files sections are not detected by rpmbuild => the reviewer must > examine package contents (with rpmls e.g.) manually. > > > [There's even a third case: Programs that load and display documentation > files. Then, files included via %doc are also installed and expected in > different directories. Packager should not simply remove duplicated files > without verifying that the documentation can still be displayed from within > the program.] > > >> My interpretation is that this is for a single file listed in the %file(s) >> section of a package and its sub-packages more than once. > > That would be both cases I cover above. > > Any suggestion for a better wording of the current guideline? > In particular, it refers to "the %files listing" (singular!) and > not all %files listings [including subpackages]. > > How about: """ A Fedora package must not list a file more than once in the spec file's %files listings. """ -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 a.badger at gmail.com Fri Feb 13 22:19:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Feb 2009 14:19:01 -0800 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <200902052308.55347.ville.skytta@iki.fi> References: <200901280136.37005.ville.skytta@iki.fi> <4980A9C4.6000902@math.unl.edu> <200901282148.35660.ville.skytta@iki.fi> <200902052308.55347.ville.skytta@iki.fi> Message-ID: <4995F1D5.9020607@gmail.com> Ville Skytt? wrote: > Hello, > > So I gather as the result of this discussion would be: > > ---- > %post > touch --no-create %{_datadir}/icons/hicolor &>/dev/null || : > > %postun > if [ $1 -eq 0 ] ; then > touch --no-create %{_datadir}/icons/hicolor &>/dev/null > gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > fi > > %posttrans > gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > ---- > > Initial install and upgrades are handled by %post and %posttrans, final erase > by %postun. Anything more to tweak? If not, is this discussion (see also 1) > in my initial mail [0]) and summary enough for the FPC so you can look into > it in a near future meeting? > https://fedoraproject.org/wiki/PackagingDrafts/Icon_Cache Does that look good? Couple questions, in the %postun, there's no || : for the touch. Is that intentional? (If not, please change it for me :-) If %posttrans should prove controversial (I don't see a problem but if it is) is including the gtk-update-icon-cache call in %post in its modified state acceptable to the proposal as a whole? -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 ville.skytta at iki.fi Sat Feb 14 21:21:26 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 14 Feb 2009 23:21:26 +0200 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <4995F1D5.9020607@gmail.com> References: <200901280136.37005.ville.skytta@iki.fi> <200902052308.55347.ville.skytta@iki.fi> <4995F1D5.9020607@gmail.com> Message-ID: <200902142321.28120.ville.skytta@iki.fi> On Saturday 14 February 2009, Toshio Kuratomi wrote: > https://fedoraproject.org/wiki/PackagingDrafts/Icon_Cache > > Does that look good? Yep, pretty much. I found some things that could be improved, and reworded the first paragraph. > Couple questions, in the %postun, there's no || : for the touch. Is > that intentional? Yes. Only the final exit statuses of the scriptlets matter here. > If %posttrans should prove controversial (I don't see a problem but if > it is) is including the gtk-update-icon-cache call in %post in its > modified state acceptable to the proposal as a whole? I'm not sure I understand you correctly. Do you mean that if %posttrans for some reason is not accepted, just move the g-u-i-c call from %posttrans to %post? I suppose that would work, but it would result in icons that are removed on package upgrades left behind in the GTK icon cache. Dunno if that's a problem at all, but my initial proposal did not have that issue: https://www.redhat.com/archives/fedora-packaging/2009-January/msg00138.html From ville.skytta at iki.fi Sat Feb 14 21:38:18 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 14 Feb 2009 23:38:18 +0200 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <4995EE70.6030805@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> Message-ID: <200902142338.18818.ville.skytta@iki.fi> On Saturday 14 February 2009, Toshio Kuratomi wrote: > """ > A Fedora package must not list a file more than once in the spec file's > %files listings. > """ This would mean that tiny -common subpackages containing for example only "%doc README COPYING" and perhaps a common base dir and/or a common config file would have to be always created if a specfile creates two otherwise independent binary packages. Is that really always desirable? From a.badger at gmail.com Sat Feb 14 22:50:25 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 14 Feb 2009 14:50:25 -0800 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <200902142338.18818.ville.skytta@iki.fi> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> <200902142338.18818.ville.skytta@iki.fi> Message-ID: <49974AB1.1000600@gmail.com> Ville Skytt? wrote: > On Saturday 14 February 2009, Toshio Kuratomi wrote: > >> """ >> A Fedora package must not list a file more than once in the spec file's >> %files listings. >> """ > > This would mean that tiny -common subpackages containing for example > only "%doc README COPYING" and perhaps a common base dir and/or a common > config file would have to be always created if a specfile creates two > otherwise independent binary packages. Is that really always desirable? > That's undesirable but is that what it means? I see a lot of cases where we ship with README, COPYING, etc in one of a set of package+subpackages and the other subpackages contain no documentation. -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 mschwendt at gmail.com Sun Feb 15 09:09:29 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 15 Feb 2009 10:09:29 +0100 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <200902142338.18818.ville.skytta@iki.fi> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> <200902142338.18818.ville.skytta@iki.fi> Message-ID: <20090215100929.623833d3.mschwendt@gmail.com> On Sat, 14 Feb 2009 23:38:18 +0200, Ville wrote: > On Saturday 14 February 2009, Toshio Kuratomi wrote: > > > """ > > A Fedora package must not list a file more than once in the spec file's > > %files listings. > > """ > > This would mean that tiny -common subpackages containing for example > only "%doc README COPYING" and perhaps a common base dir and/or a common > config file would have to be always created if a specfile creates two > otherwise independent binary packages. Is that really always desirable? For a MUST item in the guidelines, it is much too short and vague. How about: In a Fedora package .spec file, any of the files/dirs installed in the buildroot must not be included in the package(s) %files lists more than once. Unless there is good reason, and in that case there ought to be a comment in the .spec file. From christoph.wickert at googlemail.com Sun Feb 15 13:16:43 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Sun, 15 Feb 2009 14:16:43 +0100 Subject: [Fedora-packaging] Guidelines for waf usage? Message-ID: <1234703803.3384.53.camel@localhost.localdomain> Are there any guidelines, hints or whatever for using the waf build tool in Fedora? A search in the wiki returns nothing and looking though some specs I see they all handle way different. Regards, Christoph From a.badger at gmail.com Sun Feb 15 18:59:30 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 15 Feb 2009 10:59:30 -0800 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <20090215100929.623833d3.mschwendt@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> <200902142338.18818.ville.skytta@iki.fi> <20090215100929.623833d3.mschwendt@gmail.com> Message-ID: <49986612.3080803@gmail.com> Michael Schwendt wrote: > On Sat, 14 Feb 2009 23:38:18 +0200, Ville wrote: > >> On Saturday 14 February 2009, Toshio Kuratomi wrote: >> >>> """ >>> A Fedora package must not list a file more than once in the spec file's >>> %files listings. >>> """ >> This would mean that tiny -common subpackages containing for example >> only "%doc README COPYING" and perhaps a common base dir and/or a common >> config file would have to be always created if a specfile creates two >> otherwise independent binary packages. Is that really always desirable? > > For a MUST item in the guidelines, it is much too short and vague. > How about: > > In a Fedora package .spec file, any of the files/dirs installed in > the buildroot must not be included in the package(s) %files lists more > than once. Unless there is good reason, and in that case there ought to > be a comment in the .spec file. > What's an example of a good reason? (For instance, I want to know if including README/COPYING in multiple subpackages is best practice or should be frowned upon). -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 mschwendt at gmail.com Sun Feb 15 20:28:55 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 15 Feb 2009 21:28:55 +0100 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <49986612.3080803@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> <200902142338.18818.ville.skytta@iki.fi> <20090215100929.623833d3.mschwendt@gmail.com> <49986612.3080803@gmail.com> Message-ID: <20090215212855.5044c3ed.mschwendt@gmail.com> On Sun, 15 Feb 2009 10:59:30 -0800, Toshio wrote: > > How about: > > > > In a Fedora package .spec file, any of the files/dirs installed in > > the buildroot must not be included in the package(s) %files lists more > > than once. Unless there is good reason, and in that case there ought to > > be a comment in the .spec file. > > > What's an example of a good reason? A comment in the spec files which explains _why_ the files are duplicated. ;-) > (For instance, I want to know if including README/COPYING in multiple > subpackages is best practice or should be frowned upon). Can you point to a package that does that? Perhaps examining specific pkgs would help? If it shall be possible to install the subpackages individually and separate from eachother, that may be reason enough to include such %doc files in each pkg as a matter of convenience for the user [and as not to create a -common pkg for just a few files]. Same applies to directories, as not to create a -common pkg just for directory ownership. In general, it may even be applicable to scripts and binaries shared by separately installable subpackages. If it's a lib pkg that includes the docs a 2nd time in the -devel pkg, that would be bad. In particular because usually the -devel pkg requires the main lib pkg -- and because our placement of %doc files is broken. Every subpackage creates its own docdir, which means that a lib and its -devel pkg put their %doc files into two docdirs. Or not a good reason would be if a packager duplicates files in subpkgs just to make rpmlint ("No documentation") happy. From eric.tanguy at univ-nantes.fr Sun Feb 15 21:25:25 2009 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sun, 15 Feb 2009 22:25:25 +0100 Subject: [Fedora-packaging] Build failed in rawhide Message-ID: <49988845.50209@univ-nantes.fr> Someone could help me to understand why a package build fine for F-10 : http://koji.fedoraproject.org/koji/taskinfo?taskID=1128601 and the same package fail for rawhide : http://koji.fedoraproject.org/koji/taskinfo?taskID=1128665 Thanks Eric From a.badger at gmail.com Sun Feb 15 21:55:09 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 15 Feb 2009 13:55:09 -0800 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <20090215212855.5044c3ed.mschwendt@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> <200902142338.18818.ville.skytta@iki.fi> <20090215100929.623833d3.mschwendt@gmail.com> <49986612.3080803@gmail.com> <20090215212855.5044c3ed.mschwendt@gmail.com> Message-ID: <49988F3D.1030406@gmail.com> Michael Schwendt wrote: > On Sun, 15 Feb 2009 10:59:30 -0800, Toshio wrote: > >>> How about: >>> >>> In a Fedora package .spec file, any of the files/dirs installed in >>> the buildroot must not be included in the package(s) %files lists more >>> than once. Unless there is good reason, and in that case there ought to >>> be a comment in the .spec file. >>> >> What's an example of a good reason? > > A comment in the spec files which explains _why_ the files are duplicated. ;-) > I mean, what are examples when packagers should include files or directories in two %files sections for separate subpackages. >> (For instance, I want to know if including README/COPYING in multiple >> subpackages is best practice or should be frowned upon). > > Can you point to a package that does that? > Perhaps examining specific pkgs would help? > Nope. Villa said this would be a reason that packagers would have to resort to a separate subpackage for the docs. I'm sort of questioning whether this ever comes up in practice. > If it shall be possible to install the subpackages individually and > separate from eachother, that may be reason enough to include such %doc > files in each pkg as a matter of convenience for the user [and as not to > create a -common pkg for just a few files]. Same applies to directories, > as not to create a -common pkg just for directory ownership. In general, > it may even be applicable to scripts and binaries shared by separately > installable subpackages. > Do we have examples of where this is a problem? Most subpackages would depend on their main package and that package could create the directories needed by the independent parts. I understand the theory here but I'd like to see some examples of where this is a real-life problem so we can point people at it. This has gone from a clarification of wording to downgrading a MUST to a SHOULD. I'd like to understand what problems we're solving by doing that so we can write better Guidance of when it's appropriate and not appropriate to duplicate files in different sections. Otherwise people who just want to check off review items aren't going to understand when it's sufficient to merely comment something out of the ordinary and when the out-of-the-ordinary should be changed. > If it's a lib pkg that includes the docs a 2nd time in the -devel pkg, > that would be bad. In particular because usually the -devel pkg requires > the main lib pkg -- and because our placement of %doc files is broken. > Every subpackage creates its own docdir, which means that a lib and its > -devel pkg put their %doc files into two docdirs. > > Or not a good reason would be if a packager duplicates files in subpkgs > just to make rpmlint ("No documentation") happy. > Yep, agreed on both counts that a package that does this should be corrected instead of being commented and passed through review. -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 rdieter at math.unl.edu Sun Feb 15 22:07:03 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 15 Feb 2009 16:07:03 -0600 Subject: [Fedora-packaging] Build failed in rawhide In-Reply-To: <49988845.50209@univ-nantes.fr> References: <49988845.50209@univ-nantes.fr> Message-ID: <49989207.9000400@math.unl.edu> Eric Tanguy wrote: > Someone could help me to understand why a package build fine for F-10 : > http://koji.fedoraproject.org/koji/taskinfo?taskID=1128601 and the same > package fail for rawhide : > http://koji.fedoraproject.org/koji/taskinfo?taskID=1128665 Recently introduced qt-4.5-rc1 may be the culprit. bugzilla.redhat.com please. -- Rex From mschwendt at gmail.com Mon Feb 16 09:08:57 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 16 Feb 2009 10:08:57 +0100 Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <49988F3D.1030406@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> <200902142338.18818.ville.skytta@iki.fi> <20090215100929.623833d3.mschwendt@gmail.com> <49986612.3080803@gmail.com> <20090215212855.5044c3ed.mschwendt@gmail.com> <49988F3D.1030406@gmail.com> Message-ID: <20090216100857.e6e6a307.mschwendt@gmail.com> On Sun, 15 Feb 2009 13:55:09 -0800, Toshio wrote: > I mean, what are examples when packagers should include files or > directories in two %files sections for separate subpackages. No -common pkg, no shared main pkg, but multiple subpackages which may be installed independently. Imagine plugin pkgs: one for MySQL, another one for Postgresql, even another one for SQLite ... you may want to put %doc files into each subpkg. One can expand that line of thinking and also duplicate directories and other types of files in each subpkg -- and consider a common pkg only if the gain would be big enough. Whether packages SHOULD duplicate files/dirs or MAY do it, is another question. According to the current guideline it MUST NOT be done. Concerning %doc license texts, the ReviewGuidelines are not clear enough with regard to subpkgs. > This has gone from a clarification of wording to downgrading a MUST to a > SHOULD. Sure. A guideline that is not understood cannot really be mandatory, unless we follow such guidelines blindly nowadays. Hence we're reviewing this guideline, and if nobody raises a hand and gives an explanation, it's better to modify the guideline until examples are shown. > Otherwise people > who just want to check off review items aren't going to understand when > it's sufficient to merely comment something out of the ordinary and when > the out-of-the-ordinary should be changed. How do they process this review item currently? IMO, they simply tick off the item like an annoying checkbox without really performing any tests related to "rpmls/rpm -qlvp". Or they only watch for rpmbuild's lame warnings. Unowned directories and entire trees (not just below %datadir) included in multiple subpkgs are evidence of that. With my reduced reviewing activity, I still run into packagers, who are not familiar with their %files lists or who run into packaging pitfalls related to %files lists. From nicolas.mailhot at laposte.net Mon Feb 16 09:47:51 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 16 Feb 2009 10:47:51 +0100 (CET) Subject: [Fedora-packaging] Guidelines#DuplicateFiles clarification In-Reply-To: <20090216100857.e6e6a307.mschwendt@gmail.com> References: <20090212145810.bce82ec8.mschwendt@gmail.com> <20090213204634.68eb2ae0.mschwendt@gmail.com> <4995EE70.6030805@gmail.com> <200902142338.18818.ville.skytta@iki.fi> <20090215100929.623833d3.mschwendt@gmail.com> <49986612.3080803@gmail.com> <20090215212855.5044c3ed.mschwendt@gmail.com> <49988F3D.1030406@gmail.com> <20090216100857.e6e6a307.mschwendt@gmail.com> Message-ID: Le Lun 16 f?vrier 2009 10:08, Michael Schwendt a ?crit : > > On Sun, 15 Feb 2009 13:55:09 -0800, Toshio wrote: > >> I mean, what are examples when packagers should include files or >> directories in two %files sections for separate subpackages. > > No -common pkg, no shared main pkg, but multiple subpackages which may > be > installed independently. Imagine plugin pkgs: one for MySQL, another > one > for Postgresql, even another one for SQLite ... you may want to put > %doc files into each subpkg. However, the problem with "MAY" is that it's very difficult to document simply and complex guidelines are guidelines no one understands or follows. For better or worse multi-font packages use the -common model. It's probably massively overkill when -common just has one .txt file in it (plus a dir, plus correct deps), but every single attempt on my part to document "MAY" resulted in problems for the unwary packager or reviewer (in some cases, rather embarrassingly, me included). So my target now is to have subpackages as simple as possible, dep complexity in -common, and too bad if -common is tiny in many cases. It's better than spread dep complexity over many subpackages and have to explain releng why a big pdf/doc documentation file is duplicated many times over. -- Nicolas Mailhot From Fedora at FamilleCollet.com Mon Feb 16 18:09:21 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 16 Feb 2009 19:09:21 +0100 Subject: [Fedora-packaging] Proposed Changes to PHP Guidelines Message-ID: <4999ABD1.8070406@FamilleCollet.com> Proposed Changes to PHP Guidelines that need to be reviewed or ratified by the Fedora Packaging Comittee and FESCo : The changes https://fedoraproject.org/w/index.php?title=PackagingDrafts%2FPHP&diff=78843&oldid=78835 The result https://fedoraproject.org/wiki/PackagingDrafts/PHP Regards From cooly at gnome.eu.org Mon Feb 16 19:57:02 2009 From: cooly at gnome.eu.org (Lucian Langa) Date: Mon, 16 Feb 2009 21:57:02 +0200 Subject: [Fedora-packaging] review cgilib issues In-Reply-To: <4999BE20.7090102@ioa.s.u-tokyo.ac.jp> References: <1234808110.20587.130.camel@mayday> <4999BE20.7090102@ioa.s.u-tokyo.ac.jp> Message-ID: <1234814222.20587.160.camel@mayday> Hello, I'm currently reviewing cgilib package (#450050). The same functionality is provided by a similar package already in fedora libcgi. I would initially suggest using Conflicts for cgilib as those two package will most obviously conflict. Mamoru was kind enough to detail this issues a little further: * For these packages both packages the library named "libcgi.so.1", which is really a problem. - In this case a simple conflict method (like "Conflicts: libcgi" on cgilib") won't work as you desire, where there are some packages which Requires libcgi.so.1, because - An admin tries to install the package by "yum install foo" (where foo has the dependency for libcgi.so.1) - yum tries to resolve the dependency on foo, then finds that two packages have "Provides: libcgi.so.1". - Then yum will install either of libcgi or cgilib according to yum's implementation, i.e. we cannot expect which will actually be installed. However foo requires one of them, and perhaps foo won't work with the other one. - Here "Conflicts" does not work, because yum will try to install one of them, not both. * Another problem is that the soname major version "1" on libcgi.so."1" in libcgi (in Fedora) was, actually, arbitrarily chosen by Fedora maintainer, not by the upstream. And unfortunately this decision now conflicts with cgilib. - You can check this from libcgi srpm, especially libcgi-1.0-Makefile.in.patch in libcgi.srpm. The original upstream tarball only creates libcgi.so with no soname, however the Fedora maintainer seems to have created a patch to add the proper soname to libcgi.so. Then the soname "libcgi.so.1" seems to have chosen. Actually on Debian (as far as I checked debian's libcgi) the soname is libcgi.so."0" (and here .0 was arbitrarily chosen by Debian's maintainer). Any thoughts on this ? Thank you, --lucian From Jochen at herr-schmitt.de Mon Feb 16 20:12:49 2009 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 16 Feb 2009 21:12:49 +0100 Subject: [Fedora-packaging] review cgilib issues In-Reply-To: <1234814222.20587.160.camel@mayday> References: <1234808110.20587.130.camel@mayday> <4999BE20.7090102@ioa.s.u-tokyo.ac.jp> <1234814222.20587.160.camel@mayday> Message-ID: <4999C8C1.3000201@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lucian Langa schrieb: > Hello, > > I'm currently reviewing cgilib package (#450050). The same > functionality is provided by a similar package already in fedora > libcgi. I would initially suggest using Conflicts for cgilib as > those two package will most obviously conflict. Mamoru was kind > enough to detail this issues a little further: > I think you should renamed the created library into libcgilib. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmZyMEACgkQT2AHK6txfgzKpACfbt6SAX4llRDVoFEsBndg45yz t7AAnRSHBXEyuPUdTLWxrc9r4WtTOvGV =6b7s -----END PGP SIGNATURE----- From dominik at greysector.net Mon Feb 16 20:16:46 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 16 Feb 2009 21:16:46 +0100 Subject: [Fedora-packaging] review cgilib issues In-Reply-To: <1234814222.20587.160.camel@mayday> References: <1234808110.20587.130.camel@mayday> <4999BE20.7090102@ioa.s.u-tokyo.ac.jp> <1234814222.20587.160.camel@mayday> Message-ID: <20090216201645.GC25385@mokona.greysector.net> On Monday, 16 February 2009 at 20:57, Lucian Langa wrote: > Hello, > > I'm currently reviewing cgilib package (#450050). > The same functionality is provided by a similar package already in > fedora libcgi. > I would initially suggest using Conflicts for cgilib as those two > package will most obviously conflict. > Mamoru was kind enough to detail this issues a little further: > > * For these packages both packages the library named "libcgi.so.1", > which is really a problem. > - In this case a simple conflict method (like "Conflicts: libcgi" > on cgilib") won't work as you desire, where there are some packages > which Requires libcgi.so.1, because > - An admin tries to install the package by "yum install foo" > (where foo has the dependency for libcgi.so.1) > - yum tries to resolve the dependency on foo, then finds that > two packages have "Provides: libcgi.so.1". > - Then yum will install either of libcgi or cgilib according to > yum's implementation, i.e. we cannot expect which will actually > be installed. However foo requires one of them, and perhaps > foo won't work with the other one. > - Here "Conflicts" does not work, because yum will try to > install one of them, not both. > > * Another problem is that the soname major version "1" on libcgi.so."1" > in libcgi (in Fedora) was, actually, arbitrarily chosen by > Fedora maintainer, not by the upstream. And unfortunately > this decision now conflicts with cgilib. > - You can check this from libcgi srpm, especially > libcgi-1.0-Makefile.in.patch in libcgi.srpm. The original upstream > tarball only creates libcgi.so with no soname, however the Fedora > maintainer seems to have created a patch to add the proper > soname to libcgi.so. Then the soname "libcgi.so.1" seems to have > chosen. > Actually on Debian (as far as I checked debian's libcgi) > the soname is libcgi.so."0" (and here .0 was arbitrarily chosen > by Debian's maintainer). > > Any thoughts on this ? I think we cannot have two packages both providing a library with the same filename and soname while being incompatible (as in: not a drop-in replacement). One of them must be renamed. Unrelated to this, libcgi maintainer should not have chosen to use libcgi.so.1 as the soname without upstream's approval. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mschwendt at gmail.com Mon Feb 16 21:36:07 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Mon, 16 Feb 2009 22:36:07 +0100 Subject: [Fedora-packaging] review cgilib issues In-Reply-To: <20090216201645.GC25385@mokona.greysector.net> References: <1234808110.20587.130.camel@mayday> <4999BE20.7090102@ioa.s.u-tokyo.ac.jp> <1234814222.20587.160.camel@mayday> <20090216201645.GC25385@mokona.greysector.net> Message-ID: <20090216223607.27859388.mschwendt@gmail.com> On Mon, 16 Feb 2009 21:16:46 +0100, Dominik wrote: > Unrelated to this, libcgi maintainer should not have chosen to use > libcgi.so.1 as the soname without upstream's approval. Not the first time this has happened. It's reviewer's responsibility to not approve such packages. Current guidelines disallow static libs, reviewers point that out, packagers make up a soname and version, and reviewers accept it. Instead, they ought to reject such packages and request involvement of upstream developers in deciding on a soname and library versioning scheme. From tibbs at math.uh.edu Mon Feb 16 23:17:41 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 16 Feb 2009 17:17:41 -0600 Subject: [Fedora-packaging] review cgilib issues In-Reply-To: <20090216223607.27859388.mschwendt@gmail.com> (Michael Schwendt's message of "Mon\, 16 Feb 2009 22\:36\:07 +0100") References: <1234808110.20587.130.camel@mayday> <4999BE20.7090102@ioa.s.u-tokyo.ac.jp> <1234814222.20587.160.camel@mayday> <20090216201645.GC25385@mokona.greysector.net> <20090216223607.27859388.mschwendt@gmail.com> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Current guidelines disallow static libs, That is not true. They merely discourage it. "Package doesn't build as a dynamic library" is certainly sufficient justification. MS> reviewers point that out, packagers make up a soname and version, MS> and reviewers accept it. If they're going to make up a soname, they should at least start at 0. However, I don't see how the issue of inventing a soname is relevant here. MS> Instead, they ought to reject such packages and request MS> involvement of upstream developers in deciding on a soname and MS> library versioning scheme. Certainly we shouldn't be going to steps to turn static libraries into dynamic ones without at least trying to talk to upstream about the issue. We shouldn't be making _any_ significant alterations to any packaged software without trying to talk to upstream. - J< From mschwendt at gmail.com Tue Feb 17 06:59:53 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 17 Feb 2009 07:59:53 +0100 Subject: [Fedora-packaging] review cgilib issues In-Reply-To: References: <1234808110.20587.130.camel@mayday> <4999BE20.7090102@ioa.s.u-tokyo.ac.jp> <1234814222.20587.160.camel@mayday> <20090216201645.GC25385@mokona.greysector.net> <20090216223607.27859388.mschwendt@gmail.com> Message-ID: <20090217075953.f1edfb57.mschwendt@gmail.com> On Mon, 16 Feb 2009 17:17:41 -0600, Jason wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> Current guidelines disallow static libs, > > That is not true. They merely discourage it. "Package doesn't build > as a dynamic library" is certainly sufficient justification. The current wording, | Static libraries should only be included in exceptional circumstances. is strong enough to make some packagers add patches for creating a shared lib. > MS> reviewers point that out, packagers make up a soname and version, > MS> and reviewers accept it. > > If they're going to make up a soname, they should at least start at > 0. However, I don't see how the issue of inventing a soname is > relevant here. It's relevant in that it doesn't matter how we [Fedora Package Collection] differ from upstream and other distributions. Sometimes we differ in SONAME, e.g. %{version} as part of the SONAME, sometimes we only differ in the major library version. Preferably we don't differ in such fundamental details. It becomes worse if upstream finally decides to [re]start at .0 after packagers have had a higher version already. Starting at .0 makes sense, and usually that is done, but for interfaces which are not stable, the package maintainer either needs to bump the version accordingly or still rebuild all dependencies for lib updates and hidden ABI/API breakage. > MS> Instead, they ought to reject such packages and request > MS> involvement of upstream developers in deciding on a soname and > MS> library versioning scheme. > > Certainly we shouldn't be going to steps to turn static libraries into > dynamic ones without at least trying to talk to upstream about the > issue. We shouldn't be making _any_ significant alterations to any > packaged software without trying to talk to upstream. Library Makefiles are being changed, however, and although reviewers should notice it while examining the Patch files, nobody re-reviews changes applied in cvs. There are more questionable alterations to upstream installation defaults (not just in the Fedora pkg collection, e.g. add pkg-config templates), but they are beyond the scope of this reply. In general, though, we don't want to create -devel packages to be used by software developers running Fedora, that lead to software releases which are incompatible with non-Fedora installations. From dominik at greysector.net Tue Feb 17 23:10:15 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 18 Feb 2009 00:10:15 +0100 Subject: [Fedora-packaging] [Draft][RFC] The use of alternatives In-Reply-To: <4999ABD1.8070406@FamilleCollet.com> References: <4999ABD1.8070406@FamilleCollet.com> Message-ID: <20090217231014.GA8369@mokona.greysector.net> Hi all, Here's a draft that - after deciding which solution is best - should eventually be put into Packaging Guidelines: https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives I tried to list all pros and cons of each solution. I'm personally hesitating between using %ghost or Provides:, but I'd prefer the Provides: solution. What do you think? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From steve at lonetwin.net Wed Feb 18 01:08:35 2009 From: steve at lonetwin.net (steve) Date: Wed, 18 Feb 2009 02:08:35 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... Message-ID: <499B5F93.20806@lonetwin.net> Hi, Most of my reading these days is done on my laptop[1]. This includes both tech (docs and tutorial types) as well as non-tech books. So, I was pleasantly surprised when I saw 'diveintopython' listed in my yum search listings (I was searching for comic book readers). I like the idea of being able to 'yum install' or 'yum search', or even 'yum groupinsatall' books (or any CC content for that matter, eg: music, video ..etc). If packaging such content is encouraged, I'd gladly package most of the CC content I've accumulated. Does Fedora has a policy or guideline about these things ? regards, - steve [1] I don't think the Kindle ...or any other dedicated ebook reader for that matter, is worth the investment right now PS: Since I just subscribed to this list to ask the question above, I might as well also request someone to please review the following packages I've submitted, and sponsor me if possible. They've been languishing for some time now: https://bugzilla.redhat.com/show_bug.cgi?id=473583 https://bugzilla.redhat.com/show_bug.cgi?id=478744 -- Linux Centric Marketplace: http://www.tuxcompatible.com From gmachin at techconcepts.co.za Wed Feb 18 06:11:05 2009 From: gmachin at techconcepts.co.za (Gregory Machin) Date: Wed, 18 Feb 2009 08:11:05 +0200 Subject: [Fedora-packaging] rpmbuild and false dependancies when installing new rpm Message-ID: Hi all. I'm quite new to building rpms. I?m trying to build an rpm for lightsquid . I have got the rpm to build without any issues but now when I try and install it, it dies with missing dependencies the files are in the install list. [root at gregory-workstation ~]# rpm -i /home/builder/rpm/RPMS/noarch/lightsquid-1.7-1.noarch.rpm error: Failed dependencies: perl(common.pl) is needed by lightsquid-1.7-1.noarch perl(lightsquid.cfg) is needed by lightsquid-1.7-1.noarch [root at gregory-workstation ~]# I have also used mc to browse the contents on the rpm and the files are in it.. so why do I get this error ? I have also removed the "Requires" reference from the spec file and this did not help. I have attacked my lightsquid.spec file for review maybe a guru will see what my green eyes have missed. Thanks Regards Gregory Machin Email: gmachin at techconcepts.co.za Cell: +27 (0) 72 524 5098 gtalk: gmachin.techconcepts at gmail.com Support helpdesk at techconcepts.co.za Tell: +27 (0) 11 803 2169 Fax: +27 (0) 11 803 2189 After Hours Cell: +27 (0) 82 790 0796 -------------- next part -------------- A non-text attachment was scrubbed... Name: lightsquid-1.7.1.spec Type: application/octet-stream Size: 13685 bytes Desc: lightsquid-1.7.1.spec URL: From mschwendt at gmail.com Wed Feb 18 07:42:41 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 18 Feb 2009 08:42:41 +0100 Subject: [Fedora-packaging] rpmbuild and false dependancies when installing new rpm In-Reply-To: References: Message-ID: <20090218084241.edb9d1e9.mschwendt@gmail.com> On Wed, 18 Feb 2009 08:11:05 +0200, Gregory wrote: > Hi all. > > I'm quite new to building rpms. > > I?m trying to build an rpm for lightsquid . I have got the rpm to build without any issues but now when I try and install it, it dies with missing dependencies the files are in the install list. > > > > [root at gregory-workstation ~]# rpm -i /home/builder/rpm/RPMS/noarch/lightsquid-1.7-1.noarch.rpm > > error: Failed dependencies: > > perl(common.pl) is needed by lightsquid-1.7-1.noarch > > perl(lightsquid.cfg) is needed by lightsquid-1.7-1.noarch > > [root at gregory-workstation ~]# > > > > > I have also used mc to browse the contents on the rpm and the files are in it.. so why do I get this error ? > These are not dependencies on files. These are automatically generated dependencies on Perl modules, found by rpmbuild when scanning files for Perl "use"/"require". These two modules are not made available in standard search path, however, and don't declare the module name with "package" either. You may need to filter them out, especially if the modules really are not put into Perl module search path. Documentation can be found in the Wiki. P.S. Your post does not point to the src.rpm From tcallawa at redhat.com Wed Feb 18 15:33:04 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 18 Feb 2009 10:33:04 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499B5F93.20806@lonetwin.net> References: <499B5F93.20806@lonetwin.net> Message-ID: <499C2A30.1040104@redhat.com> On 2009-02-17 at 20:08:35 -0500, steve wrote: > Hi, > > Most of my reading these days is done on my laptop[1]. This includes > both tech (docs and tutorial types) as well as non-tech books. > > So, I was pleasantly surprised when I saw 'diveintopython' listed in my > yum search listings (I was searching for comic book readers). > > I like the idea of being able to 'yum install' or 'yum search', or even > 'yum groupinsatall' books (or any CC content for that matter, eg: music, > video ..etc). If packaging such content is encouraged, I'd gladly > package most of the CC content I've accumulated. > > Does Fedora has a policy or guideline about these things ? We do: https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content The rule of thumb is that it must enhance the Fedora user experience. With that said, if there is interest in doing this on a large scale, it might be worth considering making a separate Fedora CC Content Repository. I'll defer that decision to FESCo. ~spot From skvidal at fedoraproject.org Wed Feb 18 15:41:13 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 18 Feb 2009 10:41:13 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499C2A30.1040104@redhat.com> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> Message-ID: <1234971673.16686.99.camel@rosebud> On Wed, 2009-02-18 at 10:33 -0500, Tom "spot" Callaway wrote: > On 2009-02-17 at 20:08:35 -0500, steve wrote: > > Hi, > > > > Most of my reading these days is done on my laptop[1]. This includes > > both tech (docs and tutorial types) as well as non-tech books. > > > > So, I was pleasantly surprised when I saw 'diveintopython' listed in my > > yum search listings (I was searching for comic book readers). > > > > I like the idea of being able to 'yum install' or 'yum search', or even > > 'yum groupinsatall' books (or any CC content for that matter, eg: music, > > video ..etc). If packaging such content is encouraged, I'd gladly > > package most of the CC content I've accumulated. > > > > Does Fedora has a policy or guideline about these things ? > > We do: > > https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content > > The rule of thumb is that it must enhance the Fedora user experience. > > With that said, if there is interest in doing this on a large scale, it > might be worth considering making a separate Fedora CC Content > Repository. I'll defer that decision to FESCo. > I'm not on fesco but I'd be interested in a content repo for things like that. -sv From foss.mailinglists at gmail.com Wed Feb 18 15:55:09 2009 From: foss.mailinglists at gmail.com (Sankarshan Mukhopadhyay) Date: Wed, 18 Feb 2009 21:25:09 +0530 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499C2A30.1040104@redhat.com> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> Message-ID: <35586fc00902180755y60b4d097n6981f4cfff761248@mail.gmail.com> On Wed, Feb 18, 2009 at 9:03 PM, Tom spot Callaway wrote: > The rule of thumb is that it must enhance the Fedora user experience. > > With that said, if there is interest in doing this on a large scale, it > might be worth considering making a separate Fedora CC Content > Repository. I'll defer that decision to FESCo. That sort of repo would indeed be good to have. -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work From jarod at redhat.com Wed Feb 18 16:21:36 2009 From: jarod at redhat.com (Jarod Wilson) Date: Wed, 18 Feb 2009 11:21:36 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <1234971673.16686.99.camel@rosebud> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <1234971673.16686.99.camel@rosebud> Message-ID: <200902181121.36372.jarod@redhat.com> On Wednesday 18 February 2009 10:41:13 seth vidal wrote: > On Wed, 2009-02-18 at 10:33 -0500, Tom "spot" Callaway wrote: > > On 2009-02-17 at 20:08:35 -0500, steve wrote: > > > Hi, > > > > > > Most of my reading these days is done on my laptop[1]. This includes > > > both tech (docs and tutorial types) as well as non-tech books. > > > > > > So, I was pleasantly surprised when I saw 'diveintopython' listed in my > > > yum search listings (I was searching for comic book readers). > > > > > > I like the idea of being able to 'yum install' or 'yum search', or even > > > 'yum groupinsatall' books (or any CC content for that matter, eg: music, > > > video ..etc). If packaging such content is encouraged, I'd gladly > > > package most of the CC content I've accumulated. > > > > > > Does Fedora has a policy or guideline about these things ? > > > > We do: > > > > https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content > > > > The rule of thumb is that it must enhance the Fedora user experience. > > > > With that said, if there is interest in doing this on a large scale, it > > might be worth considering making a separate Fedora CC Content > > Repository. I'll defer that decision to FESCo. > > > > I'm not on fesco but I'd be interested in a content repo for things like > that. Ooh, putting Linux Device Drivers in a package would be spiffy too... http://lwn.net/Kernel/LDD3/ I've filed a FESCo ticket here: https://fedorahosted.org/fesco/ticket/65 -- Jarod Wilson jarod at redhat.com From notting at redhat.com Wed Feb 18 16:46:07 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Feb 2009 11:46:07 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <1234971673.16686.99.camel@rosebud> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <1234971673.16686.99.camel@rosebud> Message-ID: <20090218164607.GC8196@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > > https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content > > > > The rule of thumb is that it must enhance the Fedora user experience. > > > > With that said, if there is interest in doing this on a large scale, it > > might be worth considering making a separate Fedora CC Content > > Repository. I'll defer that decision to FESCo. > > > > I'm not on fesco but I'd be interested in a content repo for things like > that. Ideally, for content, it shold not be tied to specific Fedora (or RHEL) versions at all - which is a pretty good reason to keep it separate from the main Fedora repo. Bill From steve at lonetwin.net Wed Feb 18 17:03:48 2009 From: steve at lonetwin.net (steve) Date: Wed, 18 Feb 2009 18:03:48 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499C2A30.1040104@redhat.com> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> Message-ID: <499C3F74.9090205@lonetwin.net> Tom "spot" Callaway wrote: > On 2009-02-17 at 20:08:35 -0500, steve wrote: >> Hi, >> >> Most of my reading these days is done on my laptop[1]. This includes >> both tech (docs and tutorial types) as well as non-tech books. >> >> So, I was pleasantly surprised when I saw 'diveintopython' listed in my >> yum search listings (I was searching for comic book readers). >> >> I like the idea of being able to 'yum install' or 'yum search', or even >> 'yum groupinsatall' books (or any CC content for that matter, eg: music, >> video ..etc). If packaging such content is encouraged, I'd gladly >> package most of the CC content I've accumulated. >> >> Does Fedora has a policy or guideline about these things ? > > We do: > > https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content > > The rule of thumb is that it must enhance the Fedora user experience. Sorry, I missed that. Yes, that makes sense. The Fedora package collection as it stands right now may not be the best place for something like this. > > With that said, if there is interest in doing this on a large scale, it > might be worth considering making a separate Fedora CC Content > Repository. I'll defer that decision to FESCo. Yes ! I do think, having a separate repo would be a good thing. Having it Fedora endorsed, might need consideration and a nod by the FESCo, though I think I'll start working on creating a yum repo and some packages with the cc content I have. regards, - steve -- Linux Centric Marketplace: http://www.tuxcompatible.com From lyos.gemininorezel at gmail.com Wed Feb 18 17:25:18 2009 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Wed, 18 Feb 2009 12:25:18 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499C3F74.9090205@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> Message-ID: <499C447E.6030809@gmail.com> steve wrote: > Tom "spot" Callaway wrote: >> On 2009-02-17 at 20:08:35 -0500, steve wrote: >>> Hi, >>> >>> Most of my reading these days is done on my laptop[1]. This includes >>> both tech (docs and tutorial types) as well as non-tech books. >>> >>> So, I was pleasantly surprised when I saw 'diveintopython' listed in my >>> yum search listings (I was searching for comic book readers). >>> >>> I like the idea of being able to 'yum install' or 'yum search', or even >>> 'yum groupinsatall' books (or any CC content for that matter, eg: >>> music, >>> video ..etc). If packaging such content is encouraged, I'd gladly >>> package most of the CC content I've accumulated. >>> >>> Does Fedora has a policy or guideline about these things ? Question... where would such content be installed? In the users ~/music , ~/video, etc? or a system-wide location? Seem, to me, like such content should be installed as a user, not root (ie., seemingly impossible with yum), because not every user on a given system will want said content. On the other hand, if installed on a system-wide location, how do you provide access to the ordinary (unprivileged) user? >> With that said, if there is interest in doing this on a large scale, it >> might be worth considering making a separate Fedora CC Content >> Repository. I'll defer that decision to FESCo. > > Yes ! I do think, having a separate repo would be a good thing. Having > it Fedora endorsed, might need consideration and a nod by the FESCo, > though I think I'll start working on creating a yum repo and some > packages with the cc content I have. > > regards, > - steve In this case, I happen to agree, though I question the use of yum to provide such content (see above). Lyos Gemini Norezel -------------- next part -------------- A non-text attachment was scrubbed... Name: Lyos_GeminiNorezel.vcf Type: text/x-vcard Size: 428 bytes Desc: not available URL: From steve at lonetwin.net Wed Feb 18 18:11:35 2009 From: steve at lonetwin.net (steve) Date: Wed, 18 Feb 2009 19:11:35 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499C447E.6030809@gmail.com> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> Message-ID: <499C4F57.1010105@lonetwin.net> Hi Lyos, Lyos Gemini Norezel wrote: > > Question... where would such content be installed? > In the users ~/music , ~/video, etc? or a system-wide location? I was thinking of doing it in a system-wide location (same as the documentation content, ie: /usr/share/{music,video,books,doc}/) ...but that's just me. Maybe if there is real interest in doing this, we could come up with a content packaging guideline of some sort. > > Seem, to me, like such content should be installed as a user, not root > (ie., seemingly impossible with yum), because not every user on a > given system will want said content. Same holds true for a lot of already packaged content (fonts, images, docs ...etc). > > On the other hand, if installed on a system-wide location, how do you > provide access to the ordinary (unprivileged) user? Same way as we already do '/usr/share/*' is readable by everybody. >> Yes ! I do think, having a separate repo would be a good thing. Having >> it Fedora endorsed, might need consideration and a nod by the FESCo, >> though I think I'll start working on creating a yum repo and some >> packages with the cc content I have. >> >> regards, >> - steve > In this case, I happen to agree, though I question the use of yum to > provide such content (see above). I think yum would be good, because it already provides a the capabilities to track (cc content could be upgraded too -- for example, the lld editions), search (...the rpm headers), arrange in groups (for example all works by certain artist) and manage (if you are like me, you can pretty soon lose track of where you downloaded stuff, not so with files that a package provide) your collections. The other advantage of course is having a repo would imply the ability to browse through the content. I am thinking we can do for content what rpm did for software. Now, all that said, if people think this discussion should not continue here, we can move it someplace else. cheers, - steve -- Linux Centric Marketplace: http://www.tuxcompatible.com From lyos.gemininorezel at gmail.com Wed Feb 18 19:02:51 2009 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Wed, 18 Feb 2009 14:02:51 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499C4F57.1010105@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> Message-ID: <499C5B5B.1000307@gmail.com> steve wrote: > Hi Lyos, > > Lyos Gemini Norezel wrote: >> >> Question... where would such content be installed? >> In the users ~/music , ~/video, etc? or a system-wide location? > I was thinking of doing it in a system-wide location (same as the > documentation content, ie: /usr/share/{music,video,books,doc}/) ...but > that's just me. Maybe if there is real interest in doing this, we > could come up with a content packaging guideline of some sort. I don't know about your system... but my system already has 349 folders in /usr/share ... which would likely be overwhelming to John Q Public. I'd suggest a different, perhaps dedicated, location if it is to be system-wide. >> Seem, to me, like such content should be installed as a user, not root >> (ie., seemingly impossible with yum), because not every user on a >> given system will want said content. > > Same holds true for a lot of already packaged content (fonts, images, > docs ...etc). The difference, I suspect, is context. Fonts are meant to be used by many different programs. Images could be background, icons, startup, etc. CC content could be more accurately likened to that of a bookshelf (in the case of ebooks), or a library, of sorts. Both are technically *content*... but the CC content you mention has a *vastly* different *context* from that of fonts, images or docs. > >>> Yes ! I do think, having a separate repo would be a good thing. >>> Having it Fedora endorsed, might need consideration and a nod by the >>> FESCo, though I think I'll start working on creating a yum repo and >>> some packages with the cc content I have. >>> >>> regards, >>> - steve >> In this case, I happen to agree, though I question the use of yum to >> provide such content (see above). > I think yum would be good, because it already provides a the > capabilities to track (cc content could be upgraded too -- for > example, the lld editions), search (...the rpm headers), arrange in > groups (for example all works by certain artist) and manage (if you > are like me, you can pretty soon lose track of where you downloaded > stuff, not so with files that a package provide) your collections. > > The other advantage of course is having a repo would imply the ability > to browse through the content. I am thinking we can do for content > what rpm did for software. True enough... though i still think it should be user controlled rather than root-controlled. Perhaps a version of yum could be modified to allow users to install such content without elevated privileges (provided, of course, that it only affects that one user)? Lyos Gemini Norezel -------------- next part -------------- A non-text attachment was scrubbed... Name: Lyos_GeminiNorezel.vcf Type: text/x-vcard Size: 428 bytes Desc: not available URL: From michel.sylvan at gmail.com Fri Feb 20 04:02:17 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 19 Feb 2009 23:02:17 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <499C5B5B.1000307@gmail.com> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> Message-ID: On Wed, Feb 18, 2009 at 2:02 PM, Lyos Gemini Norezel wrote: > steve wrote: >> >> Hi Lyos, >> >> Lyos Gemini Norezel wrote: >>> >>> Question... where would such content be installed? >>> In the users ~/music , ~/video, etc? or a system-wide location? >> >> I was thinking of doing it in a system-wide location (same as the >> documentation content, ie: /usr/share/{music,video,books,doc}/) ...but >> that's just me. Maybe if there is real interest in doing this, we could come >> up with a content packaging guideline of some sort. > > I don't know about your system... but my system already has 349 folders in > /usr/share ... which would likely be overwhelming to John Q Public. > I'd suggest a different, perhaps dedicated, location if it is to be > system-wide. > If it's under /usr, it'd really have to be somewhere in %{_datadir}, i.e. /usr/share. And given that Fedora does not even use /opt, it's hard to see it going somewhere else. Although perhaps /usr/share/fedora-cc/{books,music,video,...} is less scattered than /usr/share/{books,music,video,...}. One consideration would be to have a fedora-cc-menus similar to games-menus, that would make sure any contents appear in a reasonable place in a user's applications menu. Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From steve at lonetwin.net Fri Feb 20 12:08:30 2009 From: steve at lonetwin.net (steve at lonetwin.net) Date: Fri, 20 Feb 2009 06:08:30 -0600 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> Message-ID: <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> Hi Lyos, Michel, Thanks for your comments and interest in this. I've been thinking about this continuously since i started the thread. I have also packaged a few[1] rpms and created a yum repo. I have not announced it yet, since I keep changing my mind about how best to create the rpms, so the rpms are not consistent in naming or packaging conventions. Anyways, here are my thoughts on the issue: Quoting Michel Salim : > On Wed, Feb 18, 2009 at 2:02 PM, Lyos Gemini Norezel > wrote: >> I don't know about your system... but my system already has 349 folders in >> /usr/share ... which would likely be overwhelming to John Q Public. >> I'd suggest a different, perhaps dedicated, location if it is to be >> system-wide. >> > If it's under /usr, it'd really have to be somewhere in %{_datadir}, > i.e. /usr/share. And given that Fedora does not even use /opt, it's > hard to see it going somewhere else. Although perhaps > /usr/share/fedora-cc/{books,music,video,...} is less scattered than > /usr/share/{books,music,video,...}. I like this idea and I was thinking along the same lines. In addition to this, I was thinking about making the rpms relocatable, so that if a user prefers, the rpm could be installed under ~/fedora-cc/{books,music,video,...}[2] ...etc. There are 2 problem though: a. Yum doesn't seem to have an option to support relocatable packages (AFAICT, the '--installroot' option will assume a rpmdb under the installroot, whereas relocatable packages just install to a different directory but use the regular system-wide rpmdb, I could be wrong tho', I haven't tried it yet) b. You'd still have to be root to install these rpms. This however, is not a major issue, IMHO, since most folk are likely to install such content on boxes where they do have root access (eg: their laptops/desktops) > > One consideration would be to have a fedora-cc-menus similar to > games-menus, that would make sure any contents appear in a reasonable > place in a user's applications menu. This is a good idea too ! Thanks ! Anyway, here is what I plan on doing: - Create a set of packaging guidelines for myself, so that i am consistent in creating the specs - Explore the possibilities offered by yum (yum plugins ??) to be able to: + customize the install location of the content + pay attention to the 'Group' header for group installations, instead of needing a comps.xml - Create some rpms, buy a domain name (any suggestions ??), set up the repo and announce a beta :) ! - These might be totally crazy ...they are just idle thoughts as of now: + Explore if rpm allows for customization of headers, so that we may better describe the content + Understand the rpm format so that we can build rpms by just slapping a rpm header to a (cpio ??) archive instead of ^building^ (ie: going through the motions of %prep, %build, %install ..etc) an rpm. However, my time being limited (and the fact that i'll be taking a 2 week vacation starting next Wednesday), I do not know when this will happen. Of course I welcome comments, suggestions any any other help. regards - steve PS: like i mentioned in my previous post, if people here think this discussion is off-topic, we can move it someplace else. [1] Just these rpms actually: Advanced Linux Programming - alp-1.0-1.fc10.noarch.rpm Code Listings from Advanced Linux Programming - alp-listings-1.0-1.fc10.noarch.rpm Comic book adaption of Cory Doctorow's book Futuristic Tales of the Here and Now - corydoctorow-ftothan-pdf-1.0-1.noarch.rpm Free Culture, By Lawrence Lessig - MP3 version - freeculture-premix-mp3-1.0-1.noarch.rpm Free Culture, By Lawrence Lessig - PDF version - freeculture-premix-pdf-1.0-1.noarch.rpm Linux Device Drivers, Third Edition - ldd3-pdf-3-1.noarch.rpm [2] I am not quite sure whether we can call it fedora-cc if it is not fedora endorsed. Also, since this content is not tied down to any distro, methinks the rpm can be installed on any rpm based distro, using any package manager. From nicolas.mailhot at laposte.net Fri Feb 20 12:27:49 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 20 Feb 2009 13:27:49 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> Message-ID: <1235132869.6305.8.camel@arekh.okg> Hi Steve, 1. packaging CC non-software is a good idea as there's no reason it can not enhance our user experience as much as critical software such as xeyes or wanda the fish 2. Doing it outside Fedora proper will result in the usual third-party merging fights/conflicts we like so much 3. Experience showed relocation was a false good idea. Don't use it. The proper FHS way is to define clean file location conventions and stick to them. If you are consistent the user will adapt and add bookmarks or symlinks as he sees fit 4. RPM groups are basically deprecated. Do not try anything fancy with them. 5. In general think twice about making a different choice than the one we use for other packages, assuming you are different and current practices do not apply to you is usually a mistake. Thus, while it's fun to reinvent the wheel and resolve again known problems, if you want to actually succeed, you'd better limit your ambitions to conventional packaging. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Fri Feb 20 13:19:27 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Feb 2009 14:19:27 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> Message-ID: <20090220131927.GE2557@free.fr> On Fri, Feb 20, 2009 at 06:08:30AM -0600, steve at lonetwin.net wrote: >> If it's under /usr, it'd really have to be somewhere in %{_datadir}, >> i.e. /usr/share. And given that Fedora does not even use /opt, it's >> hard to see it going somewhere else. Although perhaps >> /usr/share/fedora-cc/{books,music,video,...} is less scattered than >> /usr/share/{books,music,video,...}. > > I like this idea and I was thinking along the same lines. In addition to > this, I was thinking about making the rpms relocatable, so that if a user > prefers, the rpm could be installed under > ~/fedora-cc/{books,music,video,...}[2] ...etc. I don't know if this level of detail is wanted right now, but using fedora-cc is not a good idea, in my opinion, it should be something more neutral, that can be also used in other distros, or become part of the FHS, so something along %{_datadir}/content/{books,music,video,...} About relocatable packages, I don't think this is very important. Pure content packages will be relocatable, sure, but I don't think this should be a goal. >> One consideration would be to have a fedora-cc-menus similar to >> games-menus, that would make sure any contents appear in a reasonable >> place in a user's applications menu. > > This is a good idea too ! Thanks ! I don't think such thing should be done outside of Fedora, I mean, all the guidelines for content only packages should also be Fedora guidelines. So this is a more general issue of having a specific menu for content, which is, in my opinion, of relevance for fedora and even for freedesktop. > Anyway, here is what I plan on doing: > - Create a set of packaging guidelines for myself, so that i am > consistent in creating the specs I think that you should really use the Fedora guidelines, and help enhancing Fedora guidelines for content that is acceptable in Fedora (like computer related books, for example, or videos, that are tied enough with Fedora or linux). And then you would use those guidelines for this repo (this doesn't preclude making a document that only holds the guidelines relevant for content that should be much simpler). > - Explore the possibilities offered by yum (yum plugins ??) to be able to: > + customize the install location of the content > + pay attention to the 'Group' header for group installations, > instead of needing a comps.xml I don't think this should be a specific goal of the project. > - Create some rpms, buy a domain name (any suggestions ??), set up the > repo and announce a beta :) ! Still in my opinion, I think it would be better first to submit to Fedora content only packages that are acceptable in Fedora. And when the guidelines are fleshed out, do your own repo. It sure can be done in parallel, if some guidelines cannot be tested in Fedora anyway. > - These might be totally crazy ...they are just idle thoughts as of now: > + Explore if rpm allows for customization of headers, so that we may > better describe the content > + Understand the rpm format so that we can build rpms by just slapping a > rpm header to a (cpio ??) archive instead of ^building^ (ie: going through > the motions of %prep, %build, %install ..etc) an rpm. I don't think you should do that, at least not in a near future. Setting up the repo with classical rpmbuild should be enough (and should be simpler than setting up a normal build system since all the rpms should be noarch). > PS: like i mentioned in my previous post, if people here think this > discussion is off-topic, we can move it someplace else. I think that this is on-topic, and that guidelines for content could be of use in fedora. > [1] Just these rpms actually: > Advanced Linux Programming - alp-1.0-1.fc10.noarch.rpm > Code Listings from Advanced Linux Programming - > alp-listings-1.0-1.fc10.noarch.rpm > Linux Device Drivers, Third Edition - ldd3-pdf-3-1.noarch.rpm I think that those may be in fedora proper, but I am not sure. Maybe somebody more knowledgable of the code vs content issue could say. > [2] I am not quite sure whether we can call it fedora-cc if it is not > fedora endorsed. Also, since this content is not tied down to any > distro, methinks the rpm can be installed on any rpm based distro, using > any package manager. As I said above, something more neutral, like 'content', would be much more apropriate. I don't think that the license nor the distribution name is of relevance here. -- Pat From steve at lonetwin.net Fri Feb 20 13:32:40 2009 From: steve at lonetwin.net (steve at lonetwin.net) Date: Fri, 20 Feb 2009 07:32:40 -0600 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <1235132869.6305.8.camel@arekh.okg> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <1235132869.6305.8.camel@arekh.okg> Message-ID: <20090220073240.owhr7jp40k080gos@lonetwin.net> Hello Nicolas, Thanks for your comments. Firstly, to your summary, i'd say ... > Thus, while it's fun to reinvent the wheel and resolve again known > problems, if you want to actually succeed, you'd better limit your > ambitions to conventional packaging. I completely agree with you on that. If anything, i am trying ^not^ to reivent the wheel, for example, I am not inclined to the idea of creating a whole different format and another set of tools to describe content and it's meta-data. For instance, the thought did occur to me to check whether yum can support a different backend than rpm (lets say a tgz with a plain text/xml file for metadata), but that would've be reinventing the wheel. rpm is good enough. In fact it is great, because it has been tried and tested and mature. Well that said ... Quoting Nicolas Mailhot : > 1. packaging CC non-software is a good idea as there's no reason it can > not enhance our user experience as much as critical software such as > xeyes or wanda the fish > > 2. Doing it outside Fedora proper will result in the usual third-party > merging fights/conflicts we like so much Oh, don't get me wrong ! I am all *for* having my such a repository fedora endorsed/supported. After all fedora already has a submission, build and distribution setup. So, if FESCo thinks having a fedora-cc repo is a good idea, I'll be most pleased. > > 3. Experience showed relocation was a false good idea. Don't use it. The > proper FHS way is to define clean file location conventions and stick to > them. If you are consistent the user will adapt and add bookmarks or > symlinks as he sees fit Umm ...well, i thought about this and seems to me that relocation *is* a bad idea for software. I can't think of the same arguments applying for content which is by it's nature self contained. > > 4. RPM groups are basically deprecated. Do not try anything fancy with > them. Yep. ok ! > > 5. In general think twice about making a different choice than the one > we use for other packages, assuming you are different and current > practices do not apply to you is usually a mistake. > That's where I hope people here can help with. So, to summarize: - I am all for not being a third-party repository - I am not convinced relocation for (essentially self-contained) content is a bad idea. - RPM Groups are deprecated, so chuck that - Your suggestions are important. I have a pretty good feeling about this. I think we are on to something. For example think of being able to "yum " with any of the content here: http://wiki.creativecommons.org/Content_Curators http://wiki.creativecommons.org/Books http://wiki.creativecommons.org/Films cheers, - steve From nicolas.mailhot at laposte.net Fri Feb 20 14:12:36 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 20 Feb 2009 15:12:36 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <20090220073240.owhr7jp40k080gos@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <1235132869.6305.8.camel@arekh.okg> <20090220073240.owhr7jp40k080gos@lonetwin.net> Message-ID: <1235139156.11051.8.camel@arekh.okg> Le vendredi 20 f?vrier 2009 ? 07:32 -0600, steve at lonetwin.net a ?crit : > Umm ...well, i thought about this and seems to me that relocation *is* > a bad idea for software. I can't think of the same arguments applying > for content which is by it's nature self contained. Content is not by nature self-contained. The WWW is mostly content and you have links and relations all over the place. By allowing relocation you: ? make yum upgrades fail ? prevent OpenOffice, for example to present a nice selection of CC images for use in impress ? prevent a book from referencing another ? prevent software from referencing manuals or books on the same field of interest ? prevent cataloging apps from emerging ? prevent sounds and videos from being reused in games ? prevent reader helpers from working (cf the existing Bible/Kuran helpers, and if done right people would write helpers for more mundane content) All this to help people engage in gratuituous file placement like in windows, when they can achieve the same effects with symlinks and filesystem mounts without breaking the installer. Relocation is a false good idea. It is broken by default as was proved many times over whenever someone actually tried to use it. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From steve at lonetwin.net Fri Feb 20 14:21:23 2009 From: steve at lonetwin.net (steve at lonetwin.net) Date: Fri, 20 Feb 2009 08:21:23 -0600 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <20090220131927.GE2557@free.fr> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> Message-ID: <20090220082123.o7cl76q28s04gs84@lonetwin.net> Hi Patrice, Thanks for your comments. Quoting Patrice Dumas : >> I like this idea and I was thinking along the same lines. In addition to >> this, I was thinking about making the rpms relocatable, so that if a user >> prefers, the rpm could be installed under >> ~/fedora-cc/{books,music,video,...}[2] ...etc. > > I don't know if this level of detail is wanted right now, but using > fedora-cc is not a good idea, in my opinion, it should be something more > neutral, that can be also used in other distros, or become part of the > FHS, so something along > > %{_datadir}/content/{books,music,video,...} Yes, that's what my footnote [2] wanted to convey > > About relocatable packages, I don't think this is very important. Pure > content packages will be relocatable, sure, but I don't think this should be > a goal. Agreed. > >>> One consideration would be to have a fedora-cc-menus similar to >>> games-menus, that would make sure any contents appear in a reasonable >>> place in a user's applications menu. >> >> This is a good idea too ! Thanks ! > > I don't think such thing should be done outside of Fedora, I mean, all the > guidelines for content only packages should also be Fedora guidelines. > > So this is a more general issue of having a specific menu for content, > which is, in my opinion, of relevance for fedora and even for freedesktop. > Agreed. >> Anyway, here is what I plan on doing: >> - Create a set of packaging guidelines for myself, so that i am >> consistent in creating the specs > > I think that you should really use the Fedora guidelines, and help enhancing > Fedora guidelines for content that is acceptable in Fedora (like computer > related books, for example, or videos, that are tied enough with Fedora or > linux). And then you would use those guidelines for this repo (this doesn't > preclude making a document that only holds the guidelines relevant for > content that should be much simpler). Ok, let me clarify. I think my post gave the impression that i was all charged up to do something new all by myself and unrelated to fedora. This is not the case. The rpms i created and the repo setup was more of a 'proof-of-concept'. I just wanted to see for myself, whether it was worthwhile to 'shoehorn' content in a software package management/distribution tool. For instance, i learned the following this: a. Naming pacakges is going to be tough, because books have long titles, such as cory doctorow's, do acronyms make sense ? b. Version numbers do not make sense for content that is not versioned c. How does one treat remixes (ie: content that has been modified and re-released by someone else). This is going to be different than software, because, the ^upstream^ are more likely to *prefer* the forks (so to say) to live side-by-side with the originals than discourage it. d. Is it acceptable to distribute content like this: http://ghosts.nin.com/main/order_options where although the content is licensed under a share-alike license[1], the actual way to get the content is to provide an email where a 'one-time download' link would be sent. So, that implies, we get around the spirit under which the content is being shared (assuming the sole intention of this policy was to track downloads). [1] http://creativecommons.org/weblog/entry/8095 So, I agree, that using the existing guidelines makes sense, and that was what i intend to do, my experiments were just that -- experiments. My Todo list was mentioned under the assumption that this is not something Fedora would see as a good fit 'within' the distribution itself. I'd be very pleased if my assumption is wrong. > >> - Explore the possibilities offered by yum (yum plugins ??) to be able to: >> + customize the install location of the content >> + pay attention to the 'Group' header for group installations, >> instead of needing a comps.xml > > I don't think this should be a specific goal of the project. ...but I do want to separate content from code. So, for example, on installing say yum-content-plugin would one be able to yum grouplist "music/nin" of course, yum search "nin" would also do, so no big deal. > >> - Create some rpms, buy a domain name (any suggestions ??), set up the >> repo and announce a beta :) ! > > Still in my opinion, I think it would be better first to submit to Fedora > content only packages that are acceptable in Fedora. And when the guidelines > are fleshed out, do your own repo. It sure can be done in parallel, if some > guidelines cannot be tested in Fedora anyway. Umm, ok. > >> - These might be totally crazy ...they are just idle thoughts as of now: >> + Explore if rpm allows for customization of headers, so that we may >> better describe the content >> + Understand the rpm format so that we can build rpms by just slapping a >> rpm header to a (cpio ??) archive instead of ^building^ (ie: >> going through >> the motions of %prep, %build, %install ..etc) an rpm. > > I don't think you should do that, at least not in a near future. Setting up > the repo with classical rpmbuild should be enough (and should be simpler than > setting up a normal build system since all the rpms should be noarch). Yeah, like I said, those sound crazy ...so, it wasn't something I would've bothered with right away. > >> PS: like i mentioned in my previous post, if people here think this >> discussion is off-topic, we can move it someplace else. > > I think that this is on-topic, and that guidelines for content could > be of use > in fedora. Cool ! >> [1] Just these rpms actually: >> Advanced Linux Programming - alp-1.0-1.fc10.noarch.rpm >> Code Listings from Advanced Linux Programming - >> alp-listings-1.0-1.fc10.noarch.rpm >> Linux Device Drivers, Third Edition - ldd3-pdf-3-1.noarch.rpm > > I think that those may be in fedora proper, but I am not sure. Maybe somebody > more knowledgable of the code vs content issue could say. Yes, i think i'll submit those anyways and see what they say on the BZ. cheers, - steve From steve at lonetwin.net Fri Feb 20 14:28:35 2009 From: steve at lonetwin.net (steve at lonetwin.net) Date: Fri, 20 Feb 2009 08:28:35 -0600 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <1235139156.11051.8.camel@arekh.okg> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <1235132869.6305.8.camel@arekh.okg> <20090220073240.owhr7jp40k080gos@lonetwin.net> <1235139156.11051.8.camel@arekh.okg> Message-ID: <20090220082835.rqgmmfgtck0w408s@lonetwin.net> Hi Nicolas, Quoting Nicolas Mailhot : > Le vendredi 20 f?vrier 2009 ? 07:32 -0600, steve at lonetwin.net a ?crit : > >> Umm ...well, i thought about this and seems to me that relocation *is* >> a bad idea for software. I can't think of the same arguments applying >> for content which is by it's nature self contained. > > Content is not by nature self-contained. The WWW is mostly content and > you have links and relations all over the place. By allowing relocation > you: > ... > > ... > Relocation is a false good idea. It is broken by default as was proved > many times over whenever someone actually tried to use it. Excellent !! wow ! just wow ! I didn't think of *any* of that. I guess i wasn't thinking 'large scale' adoption and people building on top of the content, instead of just consuming the content. Thanks a lot for your insights ! regards, - steve From mw_triad at users.sourceforge.net Fri Feb 20 19:14:17 2009 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 20 Feb 2009 13:14:17 -0600 Subject: [Fedora-packaging] Re: I wish to package some CC licensed content ... In-Reply-To: <20090220082123.o7cl76q28s04gs84@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> Message-ID: steveATlonetwin wrote: > b. Version numbers do not make sense for content that is not versioned ...but that content can still change, ergo version numbers are still important. They just won't mean much in most instances. > ...but I do want to separate content from code. I think Bill Nottingham really hit the nail on the head here with why content should be a separate repo. It's generally unlikely to be tied to a particular Fedora release, ergo putting it in a version-release repo would lead to a lot of unnecessary duplication. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "Sorry. Wrong species." -- Unknown episode of Star Trek: TNG From nicolas.mailhot at laposte.net Fri Feb 20 19:53:42 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 20 Feb 2009 20:53:42 +0100 Subject: [Fedora-packaging] Re: I wish to package some CC licensed content ... In-Reply-To: References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> Message-ID: <1235159622.19797.1.camel@arekh.okg> Le vendredi 20 f?vrier 2009 ? 13:14 -0600, Matthew Woehlke a ?crit : > I think Bill Nottingham really hit the nail on the head here with why > content should be a separate repo. It's generally unlikely to be tied to > a particular Fedora release, ergo putting it in a version-release repo > would lead to a lot of unnecessary duplication. Because our packaging guidelines do not ever change, and rpm has fossilized, right? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lyos.gemininorezel at gmail.com Fri Feb 20 21:07:12 2009 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Fri, 20 Feb 2009 16:07:12 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> Message-ID: <499F1B80.9030909@gmail.com> Michel Salim wrote: > On Wed, Feb 18, 2009 at 2:02 PM, Lyos Gemini Norezel > wrote: > >> steve wrote: >> >> I don't know about your system... but my system already has 349 folders in >> /usr/share ... which would likely be overwhelming to John Q Public. >> I'd suggest a different, perhaps dedicated, location if it is to be >> system-wide. >> > If it's under /usr, it'd really have to be somewhere in %{_datadir}, > i.e. /usr/share. And given that Fedora does not even use /opt, it's > hard to see it going somewhere else. Well... it could reside in a '/var/www' location... could it not? Such a location would make it easy for users to share the content from one server to multiple computers, and is standard across distributions. It's also, somewhat, less of a security risk, if my assumptions are correct. > Although perhaps > /usr/share/fedora-cc/{books,music,video,...} is less scattered than > /usr/share/{books,music,video,...}. > Agreed. > One consideration would be to have a fedora-cc-menus similar to > games-menus, that would make sure any contents appear in a reasonable > place in a user's applications menu. > > Regards I suspect that'll be helpful... especially for the 'John Q Public' (aka, 'Idiot Users') types. Though a symlink to 'content' in each user's "/home" would, perhaps, be better? Just food for thought. Lyos Gemini Norezel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Lyos_GeminiNorezel.vcf Type: text/x-vcard Size: 443 bytes Desc: not available URL: From lyos.gemininorezel at gmail.com Fri Feb 20 21:31:01 2009 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Fri, 20 Feb 2009 16:31:01 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <20090220082123.o7cl76q28s04gs84@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> Message-ID: <499F2115.3080306@gmail.com> steve at lonetwin.net wrote: > Quoting Patrice Dumas : > > >> I think that you should really use the Fedora guidelines, and help >> enhancing >> Fedora guidelines for content that is acceptable in Fedora (like >> computer >> related books, for example, or videos, that are tied enough with >> Fedora or >> linux). And then you would use those guidelines for this repo (this >> doesn't >> preclude making a document that only holds the guidelines relevant for >> content that should be much simpler). > > Ok, let me clarify. I think my post gave the impression that i was all > charged up to do something new all by myself and unrelated to fedora. > This is not the case. The rpms i created and the repo setup was more > of a 'proof-of-concept'. I just wanted to see for myself, whether it > was worthwhile to 'shoehorn' content in a software package > management/distribution tool. For instance, i learned the following this: > > a. Naming pacakges is going to be tough, because books have long > titles, such as cory doctorow's, do acronyms make sense ? Perhaps a good naming guideline for content would be: {type}-{author}-{title}-{versioning} for example: ebook(s)-SmithJohn-ShortTitleHere-1.01.fc9 other types would include 'music', 'video', 'musicvideo', etc. The authors name, like a library, should probably be formatted as "LastNameFirstName". 'ShortTitle' is exactly what it sounds like... something like 'Beginners Guide to Windows Networking' could be shortened to "BeginnersWindowsNetworking" or better "BeginnersNetworking" with the full title in the description field. The versioning scheme could be kept simple: Revision (ie., revision 4, release 4, etc) . Local version (ie., the number of times you modified and re-uploaded the cvs copy . fedora release (obviously) so a book on revision 4, that has been modified 4 times in cvs (rpm fixes, spec files fixes/tweaks, etc), and was packaged for fc9 would look like: ebook-SmithJohn-BeginnersNetworking-4.04.fc9 > b. Version numbers do not make sense for content that is not versioned Not all content is versioned, but you could still apply a '1.0' version number. >> I don't think this should be a specific goal of the project. > > ...but I do want to separate content from code. So, for example, on > installing say yum-content-plugin would one be able to yum grouplist > "music/nin" > > of course, yum search "nin" would also do, so no big deal. > Might be worth looking into, eventually. Just food for thought Lyos Gemini Norezel -------------- next part -------------- A non-text attachment was scrubbed... Name: Lyos_GeminiNorezel.vcf Type: text/x-vcard Size: 428 bytes Desc: not available URL: From lyos.gemininorezel at gmail.com Fri Feb 20 21:34:10 2009 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Fri, 20 Feb 2009 16:34:10 -0500 Subject: [Fedora-packaging] Re: I wish to package some CC licensed content ... In-Reply-To: <1235159622.19797.1.camel@arekh.okg> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> <1235159622.19797.1.camel@arekh.okg> Message-ID: <499F21D2.6020404@gmail.com> Nicolas Mailhot wrote: > Le vendredi 20 f?vrier 2009 ? 13:14 -0600, Matthew Woehlke a ?crit : > > >> I think Bill Nottingham really hit the nail on the head here with why >> content should be a separate repo. It's generally unlikely to be tied to >> a particular Fedora release, ergo putting it in a version-release repo >> would lead to a lot of unnecessary duplication. >> > > Because our packaging guidelines do not ever change, and rpm has > fossilized, right? > Careful Nicolas... the dripping sarcasm isn't as noticeable in text as it would be in voice. Lyos Gemini Norezel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Lyos_GeminiNorezel.vcf Type: text/x-vcard Size: 443 bytes Desc: not available URL: From pertusus at free.fr Fri Feb 20 21:34:24 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Feb 2009 22:34:24 +0100 Subject: [Fedora-packaging] Re: I wish to package some CC licensed content ... In-Reply-To: References: <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> Message-ID: <20090220213424.GA2551@free.fr> On Fri, Feb 20, 2009 at 01:14:17PM -0600, Matthew Woehlke wrote: > >> ...but I do want to separate content from code. > > I think Bill Nottingham really hit the nail on the head here with why > content should be a separate repo. It's generally unlikely to be tied to > a particular Fedora release, ergo putting it in a version-release repo > would lead to a lot of unnecessary duplication. I don't think that, for linux/free software computer (or editing) related books, this issue weights more than having to add another repo. But I may be wrong. -- Pat From pertusus at free.fr Fri Feb 20 21:57:23 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Feb 2009 22:57:23 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <20090220082123.o7cl76q28s04gs84@lonetwin.net> References: <499B5F93.20806@lonetwin.net> <499C2A30.1040104@redhat.com> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> Message-ID: <20090220215723.GB2551@free.fr> On Fri, Feb 20, 2009 at 08:21:23AM -0600, steve at lonetwin.net wrote: > > a. Naming pacakges is going to be tough, because books have long titles, > such as cory doctorow's, do acronyms make sense ? This is not an easy issue, because, contrary to software there is no convenient name that upstream choosed. So the packager is left with too much choice and contradictory objectives. * short names are better * content needs to be disambiguated from software and other content with different medium and same title * the name should allow to find which content it is as best as possible Other issues arise, what about different languages, different formats? > b. Version numbers do not make sense for content that is not versioned If the author has a versionning scheme that looks ascii ascending lets use it. Otherwise I think that the following would work Version: 0 Release: 0.X.YYYYMMDD with YYYY year, MM month and DD day (I'd do the same for a software without version, and it is indeed what I used for uread) for the document date of publishing, or of access if publishing date is not known. > c. How does one treat remixes (ie: content that has been modified and > re-released by someone else). This is going to be different than > software, because, the ^upstream^ are more likely to *prefer* the forks > (so to say) to live side-by-side with the originals than discourage it. Not an issue here, and it is the same than with forks that are both interesting (like xemacs and emacs). > d. Is it acceptable to distribute content like this: > http://ghosts.nin.com/main/order_options > > where although the content is licensed under a share-alike license[1], > the actual way to get the content is to provide an email where a > 'one-time download' link would be sent. So, that implies, we get around > the spirit under which the content is being shared (assuming the sole > intention of this policy was to track downloads). Not an issue. At least ncarg (or ncl) was like this and is in fedora. I think that the NonCommercial clause makes it not suitable for a fedora content repo, however. (not modifiable would be fine, in my opinion, but not noin commercial). > My Todo list was mentioned under the assumption that this is not > something Fedora would see as a good fit 'within' the distribution > itself. > > I'd be very pleased if my assumption is wrong. I think that there are books that fit in fedora and not in a separate repo. For example, the 'maximum rpm book', but also books that explains how to configure servers, or the svn book http://svnbook.red-bean.com/ Also videos closely realted with fedora should in my opinion be directly in fedora, like videos explaining how to use a given application. Books about programming are less obvious candidates to be directly in fedora, but still good candidates in my opinion. -- Pat From enrico.scholz at informatik.tu-chemnitz.de Sun Feb 22 14:00:13 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 22 Feb 2009 15:00:13 +0100 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <200902052308.55347.ville.skytta@iki.fi> ("Ville =?iso-8859-1?Q?Skytt=E4=22's?= message of "Thu\, 5 Feb 2009 23\:08\:54 +0200") References: <200901280136.37005.ville.skytta@iki.fi> <4980A9C4.6000902@math.unl.edu> <200901282148.35660.ville.skytta@iki.fi> <200902052308.55347.ville.skytta@iki.fi> Message-ID: <87r61q372q.fsf@sheridan.bigo.ensc.de> Ville Skytt? writes: > %postun > if [ $1 -eq 0 ] ; then > touch --no-create %{_datadir}/icons/hicolor &>/dev/null > gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > fi The 'touch' should be inconditional and outside of the 'if' block. E.g. when we have a transaction like 1. UPDATE new1 2. UPDATE old 3. UPDATE new0 4. ERASE new0 5. ERASE old 6. ERASE new1 7. %posttrans where newX have the scriptlet above and 'old' has a legacy scriptlet which executes 'gtk-update-icon-cache' everytime. Then, 'old' will update the cache in step 5 and %posttrans will be a noop. Changes in step 6 will be ignored and system has the cache from step 5. Enrico From ville.skytta at iki.fi Sun Feb 22 17:09:34 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 22 Feb 2009 19:09:34 +0200 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (=?iso-8859-1?q?icon=09cache?=) changes In-Reply-To: <87r61q372q.fsf@sheridan.bigo.ensc.de> References: <200901280136.37005.ville.skytta@iki.fi> <200902052308.55347.ville.skytta@iki.fi> <87r61q372q.fsf@sheridan.bigo.ensc.de> Message-ID: <200902221909.35248.ville.skytta@iki.fi> On Sunday 22 February 2009, Enrico Scholz wrote: > Ville Skytt? writes: > > %postun > > if [ $1 -eq 0 ] ; then > > touch --no-create %{_datadir}/icons/hicolor &>/dev/null > > gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > > fi > > The 'touch' should be inconditional and outside of the 'if' block. > E.g. when we have a transaction like > > > 1. UPDATE new1 > 2. UPDATE old > 3. UPDATE new0 > 4. ERASE new0 > 5. ERASE old > 6. ERASE new1 > 7. %posttrans > > > where newX have the scriptlet above and 'old' has a legacy scriptlet > which executes 'gtk-update-icon-cache' everytime. Then, 'old' will > update the cache in step 5 and %posttrans will be a noop. Changes in > step 6 will be ignored and system has the cache from step 5. What practical problems would that cause? The resulting icon cache could contain entries for icons that were removed in step 6, but that'd only affect scenarios where the old version of new1 in the above had icons that the new version of new1 didn't have which I bet is a very rare case and it isn't obvious to me where this would be an actual problem because references to those icons have almost certainly gone away updated desktop files shipped with the new version of new1, or will go away along with the old version of new1 if it contained desktop files that the new new1 doesn't have. Updating the timestamp of the toplevel icon dir more often than necessary would probably cause environments that auto-update their caches or the like based on the timestamp ending up doing it more often than necessary. Unless I missed something crucial, IMO this (theoretical?) problem should be just ignored, packagers should start updating their cache update scriptlets to the ones in the Wiki draft at their earliest convenience and it isn't necessary to carry around legacy cruft. From enrico.scholz at informatik.tu-chemnitz.de Sun Feb 22 18:24:57 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 22 Feb 2009 19:24:57 +0100 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <200902221909.35248.ville.skytta@iki.fi> ("Ville =?iso-8859-1?Q?Skytt=E4=22's?= message of "Sun\, 22 Feb 2009 19\:09\:34 +0200") References: <200901280136.37005.ville.skytta@iki.fi> <200902052308.55347.ville.skytta@iki.fi> <87r61q372q.fsf@sheridan.bigo.ensc.de> <200902221909.35248.ville.skytta@iki.fi> Message-ID: <87myce2uti.fsf@sheridan.bigo.ensc.de> Ville Skytt? writes: > What practical problems would that cause? The resulting icon cache could > contain entries for icons that were removed in step 6 When we do not care about this, why do we have the %postun scriptlet at all? Enrico From a.badger at gmail.com Sun Feb 22 18:47:26 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 22 Feb 2009 10:47:26 -0800 Subject: [Fedora-packaging] Three drafts Message-ID: <49A19DBE.5090802@gmail.com> I've updated the Explicit Requires draft with feedback from FESCo. It makes the guideline only apply to library Requires: http://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires === Source URL section that deals with upstream URLs that are not parsable by rpmbuild: http://fedoraproject.org/wiki/PackagingDrafts/Troublesome_source_URLs === Section to be added to package naming and linked to Conflicts Guidelines about when upstream has used generic names for a package. http://fedoraproject.org/wiki/PackagingDrafts/Common_package_names Patrice has linked me to a similar section in the Packaging Tricks section. if someone would like to merge the rationale from there, that would be helpful. Otherwise I'll try to get to it later this week. http://fedoraproject.org/wiki/PackageMaintainers/Packaging_Tricks#Use_of_common_namespace -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 a.badger at gmail.com Sun Feb 22 18:52:32 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 22 Feb 2009 10:52:32 -0800 Subject: [Fedora-packaging] [Draft][RFC] The use of alternatives In-Reply-To: <20090217231014.GA8369@mokona.greysector.net> References: <4999ABD1.8070406@FamilleCollet.com> <20090217231014.GA8369@mokona.greysector.net> Message-ID: <49A19EF0.9090701@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > Hi all, > > Here's a draft that - after deciding which solution is best - should > eventually be put into Packaging Guidelines: > > https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives > > I tried to list all pros and cons of each solution. > I'm personally hesitating between using %ghost or Provides:, but I'd > prefer the Provides: solution. > If the only con of the %ghost solution is that it conflicts with "files owned by multiple packages are forbidden" I would prefer that. This is similar to the current exception to allow multiple packages to own the same directory when they are not in a hierarchical relationship. We would need to note this reasoning (or link to this) on the Conflicts page. -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 a.badger at gmail.com Sun Feb 22 18:57:55 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 22 Feb 2009 10:57:55 -0800 Subject: [Fedora-packaging] %define => %global change accepted Message-ID: <49A1A033.5030707@gmail.com> This is an FYI to Guidelines authors past and future that FESCo and the FPC approved the change to use %global instead of %define. I don't know of anyplaces that should remain %define so I'm going to start changing everyplace on the wiki that uses %define to %global. Someone stop me if they know of an exception to this. Also, Ville, we should change the spec templates in rpmdevtools to do this as well. Would you like a bug report, patch, or you'll just take care of that? -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 ville.skytta at iki.fi Sun Feb 22 19:02:46 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 22 Feb 2009 21:02:46 +0200 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (=?iso-8859-1?q?icon=09cache?=) changes In-Reply-To: <87myce2uti.fsf@sheridan.bigo.ensc.de> References: <200901280136.37005.ville.skytta@iki.fi> <200902221909.35248.ville.skytta@iki.fi> <87myce2uti.fsf@sheridan.bigo.ensc.de> Message-ID: <200902222102.46686.ville.skytta@iki.fi> On Sunday 22 February 2009, Enrico Scholz wrote: > Ville Skytt? writes: > > What practical problems would that cause? The resulting icon cache could > > contain entries for icons that were removed in step 6 > > When we do not care about this, why do we have the %postun scriptlet at > all? Apples and oranges. Not caring about a case occurring very rarely on package updates in legacy related scenarios which is going away as packages are being updated is not the same thing that forgetting about it altogether for all updates and erase-only transactions. Granted, I don't know if dropping the %postun script altogether would cause any problems in practice. From rdieter at math.unl.edu Sun Feb 22 19:03:32 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 22 Feb 2009 13:03:32 -0600 Subject: [Fedora-packaging] [Draft][RFC] The use of alternatives In-Reply-To: <49A19EF0.9090701@gmail.com> References: <4999ABD1.8070406@FamilleCollet.com> <20090217231014.GA8369@mokona.greysector.net> <49A19EF0.9090701@gmail.com> Message-ID: <49A1A184.2020303@math.unl.edu> Toshio Kuratomi wrote: > Dominik 'Rathann' Mierzejewski wrote: >> Hi all, >> >> Here's a draft that - after deciding which solution is best - should >> eventually be put into Packaging Guidelines: >> >> https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives >> >> I tried to list all pros and cons of each solution. >> I'm personally hesitating between using %ghost or Provides:, but I'd >> prefer the Provides: solution. > If the only con of the %ghost solution is that it conflicts with "files > owned by multiple packages are forbidden" I would advocate the use of %ghost. It works, provided the contents of all the targets are the same, ie, if they all use: touch /far/bar Conflicts will arise to simply highlight pkgs not following the convention (ie, being a valuable debugging tool). -- Rex From enrico.scholz at informatik.tu-chemnitz.de Sun Feb 22 19:21:42 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 22 Feb 2009 20:21:42 +0100 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <200902222102.46686.ville.skytta@iki.fi> ("Ville =?iso-8859-1?Q?Skytt=E4=22's?= message of "Sun\, 22 Feb 2009 21\:02\:46 +0200") References: <200901280136.37005.ville.skytta@iki.fi> <200902221909.35248.ville.skytta@iki.fi> <87myce2uti.fsf@sheridan.bigo.ensc.de> <200902222102.46686.ville.skytta@iki.fi> Message-ID: <87iqn22s6x.fsf@sheridan.bigo.ensc.de> Ville Skytt? writes: >> > What practical problems would that cause? The resulting icon cache >> > could contain entries for icons that were removed in step 6 >> >> When we do not care about this, why do we have the %postun scriptlet at >> all? > > Apples and oranges. Not caring about a case occurring very rarely Package removals are occuring very rarely too... I really do not understand why you want to handle only 9x% although it would be trivial to make things race free and to catch the whole 100%. Enrico From giallu at gmail.com Sun Feb 22 20:09:40 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 22 Feb 2009 21:09:40 +0100 Subject: [Fedora-packaging] %define => %global change accepted In-Reply-To: <49A1A033.5030707@gmail.com> References: <49A1A033.5030707@gmail.com> Message-ID: On Sun, Feb 22, 2009 at 7:57 PM, Toshio Kuratomi wrote: > This is an FYI to Guidelines authors past and future that FESCo and the > FPC approved the change to use %global instead of %define. I don't know > of anyplaces that should remain %define so I'm going to start changing > everyplace on the wiki that uses %define to %global. Someone stop me if > they know of an exception to this. Will existing packages be checked and/or forced to use %global ? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From ville.skytta at iki.fi Sun Feb 22 20:15:07 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 22 Feb 2009 22:15:07 +0200 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (=?iso-8859-1?q?icon=09cache?=) changes In-Reply-To: <87iqn22s6x.fsf@sheridan.bigo.ensc.de> References: <200901280136.37005.ville.skytta@iki.fi> <200902222102.46686.ville.skytta@iki.fi> <87iqn22s6x.fsf@sheridan.bigo.ensc.de> Message-ID: <200902222215.07849.ville.skytta@iki.fi> On Sunday 22 February 2009, Enrico Scholz wrote: > I really do not > understand why you want to handle only 9x% although it would be > trivial to make things race free and to catch the whole 100%. The keyword is feasibility, and reasons were already included in my previous reply. I believe you'll find it less than trivial to come up with an implementation that is _really_ race free and _really_ catches 100%, that's where feasibility thoughts kick in. Anyway, it doesn't make much sense to continue this discussion since you haven't answered the first question (about real world problem you're trying to solve) and instead seem to be replying to/finding things to nitpick/disagree on even in messages whose bottom line pretty much agree with what you suggested (about %postun possibly being droppable). From ville.skytta at iki.fi Sun Feb 22 20:18:44 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 22 Feb 2009 22:18:44 +0200 Subject: [Fedora-packaging] %define => %global change accepted In-Reply-To: <49A1A033.5030707@gmail.com> References: <49A1A033.5030707@gmail.com> Message-ID: <200902222218.45083.ville.skytta@iki.fi> On Sunday 22 February 2009, Toshio Kuratomi wrote: > This is an FYI to Guidelines authors past and future that FESCo and the > FPC approved the change to use %global instead of %define. I don't know > of anyplaces that should remain %define so I'm going to start changing > everyplace on the wiki that uses %define to %global. Someone stop me if > they know of an exception to this. > > Also, Ville, we should change the spec templates in rpmdevtools to do > this as well. Would you like a bug report, patch, or you'll just take > care of that? I'll take care of it in git right now. No objections to opening a Bugzilla bug for tracking purposes, go ahead if you like. From a.badger at gmail.com Sun Feb 22 20:36:02 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 22 Feb 2009 12:36:02 -0800 Subject: [Fedora-packaging] %define => %global change accepted In-Reply-To: References: <49A1A033.5030707@gmail.com> Message-ID: <49A1B732.9020401@gmail.com> Gianluca Sforna wrote: > On Sun, Feb 22, 2009 at 7:57 PM, Toshio Kuratomi wrote: >> This is an FYI to Guidelines authors past and future that FESCo and the >> FPC approved the change to use %global instead of %define. I don't know >> of anyplaces that should remain %define so I'm going to start changing >> everyplace on the wiki that uses %define to %global. Someone stop me if >> they know of an exception to this. > > Will existing packages be checked and/or forced to use %global ? > > Not at this time. The reason for changing this is that many of our uses of %define only work because of a bug in rpm. %global actually is documented to have the semantics that we want. So we're updating the Guidelines to show %global and new packages should be using instead of %define. It is also a good idea for people to change from %define to %global as it can lead to unexpected behaviour when something causes rpm to have %define perform as it was documented to. However, if you are not currently triggering the conditions that cause errors, we know of no plans to fix the rpm bug so we are not requiring that you change your code now. Details here: https://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define -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 a.badger at gmail.com Sun Feb 22 20:39:24 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 22 Feb 2009 12:39:24 -0800 Subject: [Fedora-packaging] %define => %global change accepted In-Reply-To: <200902222218.45083.ville.skytta@iki.fi> References: <49A1A033.5030707@gmail.com> <200902222218.45083.ville.skytta@iki.fi> Message-ID: <49A1B7FC.2050407@gmail.com> Ville Skytt? wrote: > On Sunday 22 February 2009, Toshio Kuratomi wrote: >> Also, Ville, we should change the spec templates in rpmdevtools to do >> this as well. Would you like a bug report, patch, or you'll just take >> care of that? > > I'll take care of it in git right now. No objections to opening a Bugzilla > bug for tracking purposes, go ahead if you like. > Done: https://bugzilla.redhat.com/show_bug.cgi?id=486876 -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 michel.sylvan at gmail.com Mon Feb 23 03:42:19 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 22 Feb 2009 22:42:19 -0500 Subject: [Fedora-packaging] Guidelines for waf usage? In-Reply-To: <1234703803.3384.53.camel@localhost.localdomain> References: <1234703803.3384.53.camel@localhost.localdomain> Message-ID: On Sun, Feb 15, 2009 at 8:16 AM, Christoph Wickert wrote: > Are there any guidelines, hints or whatever for using the waf build tool > in Fedora? A search in the wiki returns nothing and looking though some > specs I see they all handle way different. > The upstream documentation is probably canonical: http://freehackers.org/~tnagy/wafbook152/index.html Which specs are you looking at? Is the "guideline" basically about whether to use the bundled waf or the system-provided one? Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From omer at mrgc.com.pk Mon Feb 23 06:21:54 2009 From: omer at mrgc.com.pk (Syed Omer Farooq) Date: Mon, 23 Feb 2009 11:21:54 +0500 Subject: [Fedora-packaging] [Draft][RFC] The use of alternatives References: <4999ABD1.8070406@FamilleCollet.com> <20090217231014.GA8369@mokona.greysector.net><49A19EF0.9090701@gmail.com> <49A1A184.2020303@math.unl.edu> Message-ID: <14B5CC309D2047E48E7F9815783D3B24@pstech01> how to postfix mysql rpm install in fedora 10 ----- Original Message ----- From: "Rex Dieter" To: "Discussion of RPM packaging standards and practices for Fedora" Sent: Monday, February 23, 2009 12:03 AM Subject: Re: [Fedora-packaging] [Draft][RFC] The use of alternatives > Toshio Kuratomi wrote: >> Dominik 'Rathann' Mierzejewski wrote: >>> Hi all, >>> >>> Here's a draft that - after deciding which solution is best - should >>> eventually be put into Packaging Guidelines: >>> >>> https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives >>> >>> I tried to list all pros and cons of each solution. >>> I'm personally hesitating between using %ghost or Provides:, but I'd >>> prefer the Provides: solution. > >> If the only con of the %ghost solution is that it conflicts with "files >> owned by multiple packages are forbidden" > > I would advocate the use of %ghost. It works, provided the contents of > all the targets are the same, ie, if they all use: > touch /far/bar > > Conflicts will arise to simply highlight pkgs not following the convention > (ie, being a valuable debugging tool). > > -- Rex > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From christoph.wickert at googlemail.com Mon Feb 23 12:16:36 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 23 Feb 2009 13:16:36 +0100 Subject: [Fedora-packaging] Guidelines for waf usage? In-Reply-To: References: <1234703803.3384.53.camel@localhost.localdomain> Message-ID: <1235391396.3370.5.camel@localhost.localdomain> Am Sonntag, den 22.02.2009, 22:42 -0500 schrieb Michel Salim: > On Sun, Feb 15, 2009 at 8:16 AM, Christoph Wickert > wrote: > > Are there any guidelines, hints or whatever for using the waf build tool > > in Fedora? A search in the wiki returns nothing and looking though some > > specs I see they all handle way different. > > > The upstream documentation is probably canonical: > > http://freehackers.org/~tnagy/wafbook152/index.html > > Which specs are you looking at? Is the "guideline" basically about > whether to use the bundled waf or the system-provided one? This is the most important question, but there are others: What log level should we use? waf is very silent by default. Fedora specific compiler flags, parallel build... > Thanks, Regards, Christoph From laubersm at fedoraproject.org Mon Feb 23 15:48:51 2009 From: laubersm at fedoraproject.org (Susan Lauber) Date: Mon, 23 Feb 2009 10:48:51 -0500 Subject: [Fedora-packaging] Update: PackageMaintainers wiki cleanup update Message-ID: On Sat, Jan 31, 2009 at 5:01 PM, Susan Lauber wrote: > > Greetings to the authors/maintainers of Package Maintainer wiki pages, > > I introduced myself last week [1] and since then I have dug into the pages and set up a task table [2] > > I have already added a category to most pages so they can all be found together [3]. > If there are others or if you create a new page just add the string [[Category:Package Maintainers]] to the bottom of the page. > > The next step is renaming so that pages are easier to find in a search. It will also make the category page easier to use. I have started making suggested in the packagemaintainers.psv [4] file in the wikirename.git repo and Update: Pages were moved this past weekend (20090222) I also did a lot of work merging the old PackageMaintainers page into the Category page itself. I think it is still too long but will continue to clean it up this week. If I missed any redirects, please let me know (or just fix them). See https://fedoraproject.org/wiki/Category:Package_Maintainers The layout has *old PackageMaintainers info at the top (maintained manually) *Sub Categories (dynamically created list) *Pages in the Category (synamically created list) *Please do NOT include subdirs / in names going forward. *All links to the old page names should redirect but going forward, please try to use the new names. *To add a page to the category add [[Category:Package_Maintainers]] to the bottom of the page. *To link to the category page from within another page use the syntax [[:Category:Package_Maintainers]] (not the extra colon at the beginning) > > ***I encourage others to check the proposed names and offer additional suggestions.*** > > I would like to have this file ready for the wikibot by the end of the week (Feb 7). > Lack of response will be seen as a vote of confidence :) > > Thanks, > Susan > > [1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01545.html > [2] https://fedoraproject.org/wiki/Docs_tasks_for_Packaging_Guide_and_related_materials#Package_Maintainer_pages > [3] https://fedoraproject.org/wiki/Category:Package_Maintainers > [4] http://git.fedorahosted.org/git/?p=wikirename.git;a=blob_plain;f=packagemaintainers.psv;hb=HEAD > with naming instructions at https://fedoraproject.org/wiki/Help:Wiki_structure > -- Susan Lauber, (RHCX, RHCA, RHCSS) Lauber System Solutions, Inc. http://www.laubersolutions.com gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974 From michel.sylvan at gmail.com Mon Feb 23 16:15:27 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 23 Feb 2009 11:15:27 -0500 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts Message-ID: One of my package, bti, now ships a bash-completion script, which needs to be installed in /etc/bash_completion.d/ . It seems that the expectation is that installing bash-completion should automagically enable all applications that provide completion scripts, and so existing packages should own /etc/bash_completion.d (rather than depending on it). Bearing that in mind, 1. Should this be included in the guidelines? Currently, none of the use cases match: to guard against renaming, and if two unrelated packages install files to a common directory I'm proposing "3. Optional dependency. If your package has a non-essential feature that is not significant enough to split off to a separate subpackage, then you may choose not to Require: the package needed for that feature, but instead own the relevant directories." Are we still not allowing optional dependencies (suggests / recommends / hints)? Otherwise, for such features, the dependency should be suggested rather than silently ignored. 2. Some packages install files in /etc/bash_completion.d without either requiring bash-completion or owning the directory: - darcs - mercurial Depending on how this is resolved, we'd need to open bugs against them with the recommended solution. Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From michel.sylvan at gmail.com Mon Feb 23 16:29:56 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 23 Feb 2009 11:29:56 -0500 Subject: [Fedora-packaging] Guidelines for waf usage? In-Reply-To: <1235391396.3370.5.camel@localhost.localdomain> References: <1234703803.3384.53.camel@localhost.localdomain> <1235391396.3370.5.camel@localhost.localdomain> Message-ID: On Mon, Feb 23, 2009 at 7:16 AM, Christoph Wickert wrote: > Am Sonntag, den 22.02.2009, 22:42 -0500 schrieb Michel Salim: >> On Sun, Feb 15, 2009 at 8:16 AM, Christoph Wickert >> wrote: >> > Are there any guidelines, hints or whatever for using the waf build tool >> > in Fedora? A search in the wiki returns nothing and looking though some >> > specs I see they all handle way different. >> > >> The upstream documentation is probably canonical: >> >> http://freehackers.org/~tnagy/wafbook152/index.html >> >> Which specs are you looking at? Is the "guideline" basically about >> whether to use the bundled waf or the system-provided one? > > This is the most important question, but there are others: What log > level should we use? waf is very silent by default. Fedora specific > compiler flags, parallel build... > This is probably a good place to discuss a guideline, and we can either add this to the wiki later, or include such a guideline document with the Waf we ship. - Bundling: assuming new Waf releases are backward-compatible, we should probably default to recommending the use of system Waf for Fedora packages, for the same reason that this is recommended in general -- there might be bugfixes, etc. that were not available when upstream did the packaging of the source. - compiler flags, logs: the following options are relevant """ CFLAGS Selects compilation options for when the C compiler is used, e.g. "-Wall". CXXFLAGS Selects compilation options for when the C++ compiler is used, e.g. "-Wall". """ Seems like CFLAGS="$RPM_BUILD_OPTS -Werror" should do the trick. - parallel build: """ JOBS The amount of parallel jobs when building targets, if no --jobs option is given. """ waf takes the short option -j as well, so this is almost identical to using make: waf build %{?_smp_mflags} It looks like there's already a page for using cmake: http://fedoraproject.org/wiki/Packaging:Cmake so the Waf page should eventually end up there, after going through PackagingDraft. Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From rc040203 at freenet.de Mon Feb 23 16:31:54 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 23 Feb 2009 17:31:54 +0100 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: References: Message-ID: <49A2CF7A.7010105@freenet.de> Michel Salim wrote: > One of my package, bti, now ships a bash-completion script, which > needs to be installed in /etc/bash_completion.d/ . It seems that the > expectation is that installing bash-completion should automagically > enable all applications that provide completion scripts, and so > existing packages should own /etc/bash_completion.d (rather than > depending on it). > > Bearing that in mind, > 1. Should this be included in the guidelines? Currently, none of the > use cases match: to guard against renaming, and if two unrelated > packages install files to a common directory > > I'm proposing "3. Optional dependency. If your package has a > non-essential feature that is not significant enough to split off to a > separate subpackage, then you may choose not to Require: the package > needed for that feature, but instead own the relevant directories." > > Are we still not allowing optional dependencies (suggests / recommends > / hints)? Otherwise, for such features, the dependency should be > suggested rather than silently ignored. > > 2. Some packages install files in /etc/bash_completion.d without > either requiring bash-completion or owning the directory: > - darcs > - mercurial IMO, this qualifies these packages as "sloppily packaged", read minor "bugs". > Depending on how this is resolved, we'd need to open bugs against them > with the recommended solution. To me, this is another incarnation of the "plugin module" issue, ie. packages install an add-on to a package, but do not strictly depend on the base package they provide a plugin for. For those cases, 2 approaches exist: 1) let all packages which provide such a plugin own the directory, they install a plugin/add-on to (This is the approach, which is being applied for packaging perl-modules) This approach, however is only functional when all packages providing such "plugins/add-ons" obey such a convention. 2) split out the plugin/add-on package into a separate package and let this spit-out package depend on the "base-package". However, both approaches, are only fully functional when all packages providing such "plugins/add-ons" obey such conventions. Ralf From ville.skytta at iki.fi Mon Feb 23 16:39:33 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 23 Feb 2009 18:39:33 +0200 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: References: Message-ID: <200902231839.34760.ville.skytta@iki.fi> On Monday 23 February 2009, Michel Salim wrote: > One of my package, bti, now ships a bash-completion script, which > needs to be installed in /etc/bash_completion.d/ . It seems that the > expectation is that installing bash-completion should automagically > enable all applications that provide completion scripts, and so > existing packages should own /etc/bash_completion.d (rather than > depending on it). FYI, apart from some general common sense packaging guidelines, I wouldn't invest too much time into this at the moment. We're working on some changes to the bash completion dir structure and probably the mechanism with which individual completions are enabled upstream, it'll hopefully be included in not too distant future releases. From michel.sylvan at gmail.com Mon Feb 23 16:44:41 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 23 Feb 2009 11:44:41 -0500 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: <49A2CF7A.7010105@freenet.de> References: <49A2CF7A.7010105@freenet.de> Message-ID: On Mon, Feb 23, 2009 at 11:31 AM, Ralf Corsepius wrote: > Michel Salim wrote: >> >> One of my package, bti, now ships a bash-completion script, which >> needs to be installed in /etc/bash_completion.d/ . It seems that the >> expectation is that installing bash-completion should automagically >> enable all applications that provide completion scripts, and so >> existing packages should own /etc/bash_completion.d (rather than >> depending on it). >> >> Bearing that in mind, >> 1. Should this be included in the guidelines? Currently, none of the >> use cases match: to guard against renaming, and if two unrelated >> packages install files to a common directory >> >> I'm proposing "3. Optional dependency. If your package has a >> non-essential feature that is not significant enough to split off to a >> separate subpackage, then you may choose not to Require: the package >> needed for that feature, but instead own the relevant directories." >> >> Are we still not allowing optional dependencies (suggests / recommends >> / hints)? Otherwise, for such features, the dependency should be >> suggested rather than silently ignored. >> >> 2. Some packages install files in /etc/bash_completion.d without >> either requiring bash-completion or owning the directory: >> - darcs >> - mercurial > > IMO, this qualifies these packages as "sloppily packaged", read minor > "bugs". > >> Depending on how this is resolved, we'd need to open bugs against them >> with the recommended solution. > > To me, this is another incarnation of the "plugin module" issue, ie. > packages install an add-on to a package, but do not strictly depend on the > base package they provide a plugin for. > > For those cases, 2 approaches exist: > > 1) let all packages which provide such a plugin own the directory, they > install a plugin/add-on to (This is the approach, which is being applied for > packaging perl-modules) > > This approach, however is only functional when all packages providing such > "plugins/add-ons" obey such a convention. > Agreed; I've not seen this use case clarified anywhere, though -- not in the general packaging guidelines, and not in the Perl guidelines. Given that it's popping up outside Perl, we probably need a general guideline. > 2) split out the plugin/add-on package into a separate package and let this > spit-out package depend on the "base-package". Seems overkill in this case, thus my wording of the proposed change. > However, both approaches, are only fully functional when all packages > providing such "plugins/add-ons" obey such conventions. Definitely. The question now is: do we amend the guidelines, or is this an "obvious" use case that does not need clarification? Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From michel.sylvan at gmail.com Mon Feb 23 16:45:30 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 23 Feb 2009 11:45:30 -0500 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: <200902231839.34760.ville.skytta@iki.fi> References: <200902231839.34760.ville.skytta@iki.fi> Message-ID: On Mon, Feb 23, 2009 at 11:39 AM, Ville Skytt? wrote: > > FYI, apart from some general common sense packaging guidelines, I wouldn't > invest too much time into this at the moment. We're working on some changes > to the bash completion dir structure and probably the mechanism with which > individual completions are enabled upstream, it'll hopefully be included in > not too distant future releases. > Ah, right. Thanks. -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From michel.sylvan at gmail.com Mon Feb 23 16:59:38 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 23 Feb 2009 11:59:38 -0500 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: <20090220215723.GB2551@free.fr> References: <499B5F93.20806@lonetwin.net> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> <20090220215723.GB2551@free.fr> Message-ID: On Fri, Feb 20, 2009 at 4:57 PM, Patrice Dumas wrote: > Other issues arise, what about different languages, different formats? Good point. Something like %{_datadir}/contents/books/foo/fr_FR/foo.{pdf,epub} or %{_datadir}/contents/books/fr_FR/foo.{pdf,epub} > >> b. Version numbers do not make sense for content that is not versioned > > If the author has a versionning scheme that looks ascii ascending lets > use it. Otherwise I think that the following would work > > Version: 0 > Release: 0.X.YYYYMMDD > > with YYYY year, MM month and DD day (I'd do the same for a software > without version, and it is indeed what I used for uread) for the document > date of publishing, or of access if publishing date is not known. > We'd probably want to encode the book's print edition in either %{version} or %{release} as well. Given that the release tag is normally associated with packaging rather than content changes (the YYYYMMDD is normally for pre-release packages), perhaps the following? Version: EDITION.YYYYMMDD Release: X or 0.X Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From nicolas.mailhot at laposte.net Mon Feb 23 17:11:42 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 23 Feb 2009 18:11:42 +0100 Subject: [Fedora-packaging] I wish to package some CC licensed content ... In-Reply-To: References: <499B5F93.20806@lonetwin.net> <499C3F74.9090205@lonetwin.net> <499C447E.6030809@gmail.com> <499C4F57.1010105@lonetwin.net> <499C5B5B.1000307@gmail.com> <20090220060830.bkg9q8iwgscw8g00@lonetwin.net> <20090220131927.GE2557@free.fr> <20090220082123.o7cl76q28s04gs84@lonetwin.net> <20090220215723.GB2551@free.fr> Message-ID: <1235409102.19033.1.camel@arekh.okg> Le lundi 23 f?vrier 2009 ? 11:59 -0500, Michel Salim a ?crit : > On Fri, Feb 20, 2009 at 4:57 PM, Patrice Dumas wrote: > >> b. Version numbers do not make sense for content that is not versioned > > > > If the author has a versionning scheme that looks ascii ascending lets > > use it. Otherwise I think that the following would work > > > > Version: 0 > > Release: 0.X.YYYYMMDD > > > > with YYYY year, MM month and DD day (I'd do the same for a software > > without version, and it is indeed what I used for uread) for the document > > date of publishing, or of access if publishing date is not known. > > > We'd probably want to encode the book's print edition in either > %{version} or %{release} as well. Given that the release tag is > normally associated with packaging rather than content changes (the > YYYYMMDD is normally for pre-release packages), perhaps the following? > > Version: EDITION.YYYYMMDD > Release: X or 0.X If upstream does not version properly there is plenty of precedent in the repository for using the timestamp of its releases as versions -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Mon Feb 23 18:03:20 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 23 Feb 2009 19:03:20 +0100 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: References: <200902231839.34760.ville.skytta@iki.fi> Message-ID: <49A2E4E8.7020102@freenet.de> Michel Salim wrote: > On Mon, Feb 23, 2009 at 11:39 AM, Ville Skytt? wrote: >> FYI, apart from some general common sense packaging guidelines, I wouldn't >> invest too much time into this at the moment. We're working on some changes >> to the bash completion dir structure and probably the mechanism with which >> individual completions are enabled upstream, it'll hopefully be included in >> not too distant future releases. >> > Ah, right. Thanks. Provided what Ville said, if I were you, let your package own /etc/bash_completion.d/ ;) Ralf From michel.sylvan at gmail.com Mon Feb 23 20:43:49 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 23 Feb 2009 15:43:49 -0500 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: <49A2E4E8.7020102@freenet.de> References: <200902231839.34760.ville.skytta@iki.fi> <49A2E4E8.7020102@freenet.de> Message-ID: On Mon, Feb 23, 2009 at 1:03 PM, Ralf Corsepius wrote: > Michel Salim wrote: >> >> On Mon, Feb 23, 2009 at 11:39 AM, Ville Skytt? >> wrote: >>> >>> FYI, apart from some general common sense packaging guidelines, I >>> wouldn't >>> invest too much time into this at the moment. We're working on some >>> changes >>> to the bash completion dir structure and probably the mechanism with >>> which >>> individual completions are enabled upstream, it'll hopefully be included >>> in >>> not too distant future releases. >>> >> Ah, right. Thanks. > > Provided what Ville said, if I were you, let your package own > /etc/bash_completion.d/ ;) > Indeed, that's what I did. Bugs filed against darcs (https://bugzilla.redhat.com/show_bug.cgi?id=487012) and mercurial (https://bugzilla.redhat.com/show_bug.cgi?id=487015) as well. Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From mschwendt at gmail.com Tue Feb 24 09:24:29 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 24 Feb 2009 10:24:29 +0100 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: References: <200902231839.34760.ville.skytta@iki.fi> <49A2E4E8.7020102@freenet.de> Message-ID: <20090224102429.894f4d8a.mschwendt@gmail.com> On Mon, 23 Feb 2009 15:43:49 -0500, Michel wrote: > On Mon, Feb 23, 2009 at 1:03 PM, Ralf Corsepius wrote: > > Michel Salim wrote: > >> > >> On Mon, Feb 23, 2009 at 11:39 AM, Ville Skytt? > >> wrote: > >>> > >>> FYI, apart from some general common sense packaging guidelines, I > >>> wouldn't > >>> invest too much time into this at the moment. We're working on some > >>> changes > >>> to the bash completion dir structure and probably the mechanism with > >>> which > >>> individual completions are enabled upstream, it'll hopefully be included > >>> in > >>> not too distant future releases. > >>> > >> Ah, right. Thanks. > > > > Provided what Ville said, if I were you, let your package own > > /etc/bash_completion.d/ ;) > > > Indeed, that's what I did. Bugs filed against darcs > (https://bugzilla.redhat.com/show_bug.cgi?id=487012) and mercurial > (https://bugzilla.redhat.com/show_bug.cgi?id=487015) as well. Which reminds me: Does anyone have a script to examine repo metadata for all dependencies on files/directories? Do we have any package in the collection that depends on a directory instead of a package name [to pull in a home directory e.g.]? From ffesti at redhat.com Tue Feb 24 09:46:59 2009 From: ffesti at redhat.com (Florian Festi) Date: Tue, 24 Feb 2009 10:46:59 +0100 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: <49A2CF7A.7010105@freenet.de> References: <49A2CF7A.7010105@freenet.de> Message-ID: <49A3C213.7080500@redhat.com> Ralf Corsepius wrote: > For those cases, 2 approaches exist: > > 1) let all packages which provide such a plugin own the directory, they > install a plugin/add-on to (This is the approach, which is being applied > for packaging perl-modules) > > This approach, however is only functional when all packages providing > such "plugins/add-ons" obey such a convention. > > 2) split out the plugin/add-on package into a separate package and let > this spit-out package depend on the "base-package". There is a third possible approach: Split out the plugin dir into a separate package and let plugin/add-on packages depend on it. > However, both approaches, are only fully functional when all packages > providing such "plugins/add-ons" obey such conventions. This stays true for all possible approaches. Florian From michel.sylvan at gmail.com Wed Feb 25 00:12:22 2009 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 24 Feb 2009 19:12:22 -0500 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: <49A3C213.7080500@redhat.com> References: <49A2CF7A.7010105@freenet.de> <49A3C213.7080500@redhat.com> Message-ID: On Tue, Feb 24, 2009 at 4:46 AM, Florian Festi wrote: > Ralf Corsepius wrote: >> >> For those cases, 2 approaches exist: >> >> 1) let all packages which provide such a plugin own the directory, they >> install a plugin/add-on to (This is the approach, which is being applied for >> packaging perl-modules) >> >> This approach, however is only functional when all packages providing such >> "plugins/add-ons" obey such a convention. >> >> 2) split out the plugin/add-on package into a separate package and let >> this spit-out package depend on the "base-package". > > There is a third possible approach: > > Split out the plugin dir into a separate package and let > plugin/add-on packages depend on it. > That is actually a very good idea. That way, you can even script the following query: "which functionality do I have plugins for?" by doing rpm -qa \*-filesystem or whichever common naming convention we settle on. Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From rc040203 at freenet.de Wed Feb 25 01:28:15 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 25 Feb 2009 02:28:15 +0100 Subject: [Fedora-packaging] Packaging clarification regarding bash-completion scripts In-Reply-To: References: <49A2CF7A.7010105@freenet.de> <49A3C213.7080500@redhat.com> Message-ID: <49A49EAF.6060605@freenet.de> Michel Salim wrote: > On Tue, Feb 24, 2009 at 4:46 AM, Florian Festi wrote: >> Ralf Corsepius wrote: >>> For those cases, 2 approaches exist: >>> >>> 1) let all packages which provide such a plugin own the directory, they >>> install a plugin/add-on to (This is the approach, which is being applied for >>> packaging perl-modules) >>> >>> This approach, however is only functional when all packages providing such >>> "plugins/add-ons" obey such a convention. >>> >>> 2) split out the plugin/add-on package into a separate package and let >>> this spit-out package depend on the "base-package". >> There is a third possible approach: >> >> Split out the plugin dir into a separate package and let >> plugin/add-on packages depend on it. >> > That is actually a very good idea. I dislike this idea. It leads to "one dir/file per package" packages and is functionally equivalent 1). > That way, you can even script the > following query: "which functionality do I have plugins for?" by doing > > rpm -qa \*-filesystem > > or whichever common naming convention we settle on. From kanarip at kanarip.com Thu Feb 26 16:41:09 2009 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 26 Feb 2009 17:41:09 +0100 Subject: [Fedora-packaging] Packaging guidelines for rubygems Message-ID: <49A6C625.4030008@kanarip.com> Hi, I find patching rubygems (for CVEs) a pain in the ass because of the packaging guideline requirement to have the rubygem package's Source0 be the actual gem. I'd much rather work from tarballs. Kind regards, Jeroen van Meeuwen -kanarip From dominik at greysector.net Thu Feb 26 18:39:36 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 26 Feb 2009 19:39:36 +0100 Subject: [Fedora-packaging] [Draft][RFC] The use of alternatives In-Reply-To: <49A1A184.2020303@math.unl.edu> References: <4999ABD1.8070406@FamilleCollet.com> <20090217231014.GA8369@mokona.greysector.net> <49A19EF0.9090701@gmail.com> <49A1A184.2020303@math.unl.edu> Message-ID: <20090226183935.GA9788@mokona.greysector.net> On Sunday, 22 February 2009 at 20:03, Rex Dieter wrote: > Toshio Kuratomi wrote: > >Dominik 'Rathann' Mierzejewski wrote: > >>Hi all, > >> > >>Here's a draft that - after deciding which solution is best - should > >>eventually be put into Packaging Guidelines: > >> > >>https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives > >> > >>I tried to list all pros and cons of each solution. > >>I'm personally hesitating between using %ghost or Provides:, but I'd > >>prefer the Provides: solution. > > >If the only con of the %ghost solution is that it conflicts with "files > >owned by multiple packages are forbidden" > > I would advocate the use of %ghost. It works, provided the contents of > all the targets are the same, ie, if they all use: > touch /far/bar > > Conflicts will arise to simply highlight pkgs not following the > convention (ie, being a valuable debugging tool). Sounds good to me. Thanks for the comments. I'll incorporate them in the draft and present it later for approval. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From xjakub at fi.muni.cz Sat Feb 28 01:15:19 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sat, 28 Feb 2009 02:15:19 +0100 Subject: [Fedora-packaging] desktop filename Message-ID: <49A89027.2010408@fi.muni.cz> Hi all, what's the proper desktop filename? Is it just %{name}.desktop or fedora-%{name}.desktop or it can be both? Desktop-file-install creates fedora-%{name}.desktop, while the Review Guidelines say it must be %{name}.desktop. I mean either the Review Guidelines are wrong in this or desktop-file-install should be fixed to follow the guidelines, what do you think about it? Regards, Milos From feng.shaun at gmail.com Fri Feb 27 01:31:00 2009 From: feng.shaun at gmail.com (Armin) Date: Thu, 26 Feb 2009 21:31:00 -0400 Subject: [Fedora-packaging] desktop filename In-Reply-To: <49A89027.2010408@fi.muni.cz> References: <49A89027.2010408@fi.muni.cz> Message-ID: <200902262131.01554.feng.shaun@gmail.com> On Friday 27 February 2009 21:15:19 Milos Jakubicek wrote: > Hi all, > > what's the proper desktop filename? Is it just %{name}.desktop or > fedora-%{name}.desktop or it can be both? > > Desktop-file-install creates fedora-%{name}.desktop, while the Review > Guidelines say it must be %{name}.desktop. > > I mean either the Review Guidelines are wrong in this or > desktop-file-install should be fixed to follow the guidelines, what do > you think about it? > > Regards, > Milos > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging I believe that the Desktop-file-install should be fixed! It's %{name}.desktop, fedora-%{name}.desktop doesn't quite make sense. -- Armin Moradi From denis at poolshark.org Sat Feb 28 08:27:41 2009 From: denis at poolshark.org (Denis Leroy) Date: Sat, 28 Feb 2009 09:27:41 +0100 Subject: [Fedora-packaging] desktop filename In-Reply-To: <49A89027.2010408@fi.muni.cz> References: <49A89027.2010408@fi.muni.cz> Message-ID: <49A8F57D.8010705@poolshark.org> Milos Jakubicek wrote: > Hi all, > > what's the proper desktop filename? Is it just %{name}.desktop or > fedora-%{name}.desktop or it can be both? > > Desktop-file-install creates fedora-%{name}.desktop, It probably does so because you're adding the "--vendor fedora" option. Just remove it, and it will keep its original name. From mschwendt at gmail.com Sat Feb 28 09:43:51 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 28 Feb 2009 10:43:51 +0100 Subject: [Fedora-packaging] %doc killing files installed below %_defaultdocdir Message-ID: <20090228104351.205a33fc.mschwendt@gmail.com> The scenario: - tarball "make install" installs lots of documentation files in %_defaultdocdir/%name-%version/ - package %files list uses %doc attributes to place its own selection of files in our default docdir => all doc files from "make install" are lost, because %doc fills %_defaultdocdir/%name-%version/ from scratch In all earlier cases where applicable, I could convince the packager to not use %doc and instead create proper %files entries to include the files found in %_defaultdocdir/%name-%version/ -- as a bonus, rpmbuild would fail for any file not included in %files. For the first time, a packager insists on overwriting/killing the installed files with his own conflicting %doc attributes. Conclusion: It works but bears risks. It would silently kill any additional documentation files built and installed by an upgrade, but not added by the packager manually via %doc. It could also be that the %doc statements create different subdirs (e.g. ./html/ versus placing the html files directory in the pkg's docdir root) which might conflict with paths compiled into an application. What do other people think about this? -- https://bugzilla.redhat.com/484933 From mtasaka at ioa.s.u-tokyo.ac.jp Sat Feb 28 10:47:24 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 28 Feb 2009 19:47:24 +0900 Subject: [Fedora-packaging] %doc killing files installed below %_defaultdocdir In-Reply-To: <20090228104351.205a33fc.mschwendt@gmail.com> References: <20090228104351.205a33fc.mschwendt@gmail.com> Message-ID: <49A9163C.7000803@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote, at 02/28/2009 06:43 PM +9:00: > The scenario: > > - tarball "make install" installs lots of documentation files in > %_defaultdocdir/%name-%version/ > > - package %files list uses %doc attributes to place its own > selection of files in our default docdir > > => all doc files from "make install" are lost, because > %doc fills %_defaultdocdir/%name-%version/ from scratch > > > In all earlier cases where applicable, I could convince the packager > to not use %doc and instead create proper %files entries to include > the files found in %_defaultdocdir/%name-%version/ -- as a bonus, > rpmbuild would fail for any file not included in %files. > > For the first time, a packager insists on overwriting/killing the > installed files with his own conflicting %doc attributes. > > > Conclusion: It works but bears risks. It would silently kill any > additional documentation files built and installed by an upgrade, but not > added by the packager manually via %doc. It could also be that the %doc > statements create different subdirs (e.g. ./html/ versus placing the > html files directory in the pkg's docdir root) which might conflict > with paths compiled into an application. > > What do other people think about this? > I have already seen that many packagers (including myself) once remove all installed document files and add them again using %doc, and I have seen no problem for this method. Mamoru From mschwendt at gmail.com Sat Feb 28 13:05:17 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 28 Feb 2009 14:05:17 +0100 Subject: [Fedora-packaging] %doc killing files installed below %_defaultdocdir In-Reply-To: <49A9163C.7000803@ioa.s.u-tokyo.ac.jp> References: <20090228104351.205a33fc.mschwendt@gmail.com> <49A9163C.7000803@ioa.s.u-tokyo.ac.jp> Message-ID: <20090228140517.9da75de0.mschwendt@gmail.com> On Sat, 28 Feb 2009 19:47:24 +0900, Mamoru wrote: > I have already seen that many packagers (including myself) once > remove all installed document files and add them again > using %doc, *scratching my head* Removing all installed document files and adding them again is not really the same. Particularly not if %doc places them elsewhere. In the scenario I refer to, no installed files get removed by the packager. They simply are lost silently/secretly. > and I have seen no problem for this method. Well, I've pointed out several risks, albeit not all. During review an entire tree of installed documentation files got lost without the packager noticing it. Still interested in feedback from more people. -- So, in case I approve the pkg with a final warning, nobody else comes later and criticises me. From pertusus at free.fr Sat Feb 28 14:32:06 2009 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 28 Feb 2009 15:32:06 +0100 Subject: [Fedora-packaging] %doc killing files installed below %_defaultdocdir In-Reply-To: <20090228140517.9da75de0.mschwendt@gmail.com> References: <20090228104351.205a33fc.mschwendt@gmail.com> <49A9163C.7000803@ioa.s.u-tokyo.ac.jp> <20090228140517.9da75de0.mschwendt@gmail.com> Message-ID: <20090228143206.GA2816@free.fr> On Sat, Feb 28, 2009 at 02:05:17PM +0100, Michael Schwendt wrote: > > Still interested in feedback from more people. In many cases, I remove things from the staged install and use %doc, sometime with using temporary directory to have a specific layout, with control over what gets installed. For a complicated example, you can have a look at xbae. I take the installed directory and then put it back in the source directory and clean it... There is some documentation you may want to expand on: http://fedoraproject.org/wiki/Packaging_tricks#Installing_documentation:_2_paths -- Pat From a.badger at gmail.com Sat Feb 28 21:55:32 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 28 Feb 2009 13:55:32 -0800 Subject: [Fedora-packaging] %doc killing files installed below %_defaultdocdir In-Reply-To: <20090228104351.205a33fc.mschwendt@gmail.com> References: <20090228104351.205a33fc.mschwendt@gmail.com> Message-ID: <49A9B2D4.3010605@gmail.com> Michael Schwendt wrote: > The scenario: > > - tarball "make install" installs lots of documentation files in > %_defaultdocdir/%name-%version/ > > - package %files list uses %doc attributes to place its own > selection of files in our default docdir > > => all doc files from "make install" are lost, because > %doc fills %_defaultdocdir/%name-%version/ from scratch > > > In all earlier cases where applicable, I could convince the packager > to not use %doc and instead create proper %files entries to include > the files found in %_defaultdocdir/%name-%version/ -- as a bonus, > rpmbuild would fail for any file not included in %files. > > For the first time, a packager insists on overwriting/killing the > installed files with his own conflicting %doc attributes. > > > Conclusion: It works but bears risks. It would silently kill any > additional documentation files built and installed by an upgrade, but not > added by the packager manually via %doc. This has risk but isn't dangerous to the program's operation. It increases the complexity inside of the spec file but may help when additional documentation is added. It changes how the packager controls what's included in the documentation. It has documentation from one subpackage being added to the doc directory of the main package... I think your method has merit but I don't think I want to mandate that it must be used instead of the other way. > It could also be that the %doc > statements create different subdirs (e.g. ./html/ versus placing the > html files directory in the pkg's docdir root) which might conflict > with paths compiled into an application. > We already say that things can't be marked %doc if the program relies on them since --nodoc can exclude those files. Maybe we need to clarify that to mention that things in the docdir are automatically marked %doc? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: