From aoliva at redhat.com Fri Aug 1 19:53:26 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 01 Aug 2008 16:53:26 -0300 Subject: [Fedora-packaging] Re: supporting closed source operating systems? In-Reply-To: <20080713163012.GB18161@victor.nirvana> (Axel Thimm's message of "Sun\, 13 Jul 2008 19\:30\:12 +0300") References: <20080708155820.GA17077@amd.home.annexia.org> <20080709215757.GC3755@victor.nirvana> <20080710212352.GA21234@victor.nirvana> <20080713153401.GB1120@amd.home.annexia.org> <20080713163012.GB18161@victor.nirvana> Message-ID: On Jul 13, 2008, Axel Thimm wrote: > So the issue is a political one, not a technical one. Supporting > libvirt for running Fedora under Windows is one thing, supporting > increased productivity on Windows another. FTR, if we were to pursue the latter, I think it might make more sense, at least from my perception of Red Hat's perspective, to join forces with Cygwin, maybe even bring it into the Fedora brand/umbrella. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From fedora at leemhuis.info Sun Aug 3 11:42:27 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Aug 2008 13:42:27 +0200 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines Message-ID: <489599A3.1070703@leemhuis.info> Hi! I noticed a few links on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines are broken due to the wiki migration. Look out for strings like "[wiki:Self:Packaging/" to find them. I might have fixed those myself, but if you guys protect that area with ACLs then you need to fix things like this yourself. Cu knurd From tcallawa at redhat.com Sun Aug 3 13:12:29 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 03 Aug 2008 09:12:29 -0400 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines In-Reply-To: <489599A3.1070703@leemhuis.info> References: <489599A3.1070703@leemhuis.info> Message-ID: <1217769149.7231.14.camel@localhost.localdomain> On Sun, 2008-08-03 at 13:42 +0200, Thorsten Leemhuis wrote: > Hi! > > I noticed a few links on > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > are broken due to the wiki migration. Look out for strings like > "[wiki:Self:Packaging/" to find them. > > I might have fixed those myself, but if you guys protect that area with > ACLs then you need to fix things like this yourself. Thanks for the heads-up, they should all be fixed now. As an aside, someone recently complained to me that they were unable to "fix a bug" in the guidelines. When I inquired further, I discovered that the bug they wanted to fix was not a bug at all, but rather, a change that would have caused a lot of broken packages if it was adopted. This is exactly why we have ACLs on the guidelines. Unfortunately, it also means that people with good intentions who really do find easy-fix bugs like these broken links can't just fix it themselves, but IMHO, it is a small price to pay. ~spot From dtimms at iinet.net.au Sun Aug 3 13:23:28 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 03 Aug 2008 23:23:28 +1000 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines In-Reply-To: <1217769149.7231.14.camel@localhost.localdomain> References: <489599A3.1070703@leemhuis.info> <1217769149.7231.14.camel@localhost.localdomain> Message-ID: <4895B150.3080902@iinet.net.au> Tom "spot" Callaway wrote: > > This is exactly why we have ACLs on the guidelines. Unfortunately, it > also means that people with good intentions who really do find easy-fix > bugs like these broken links can't just fix it themselves, but IMHO, it > is a small price to pay. Is there an easy way to create the fix, but have the wiki store it in a potential update queue - ie for approval/application ? That would mean the wiki reviewer get's to be instantly useful, yet not be able to do unexpected things to the "needing fixes" pages. We'd probably require a detailed description of the potential change along with the change itself. DaveT. From tcallawa at redhat.com Sun Aug 3 13:28:33 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 03 Aug 2008 09:28:33 -0400 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines In-Reply-To: <4895B150.3080902@iinet.net.au> References: <489599A3.1070703@leemhuis.info> <1217769149.7231.14.camel@localhost.localdomain> <4895B150.3080902@iinet.net.au> Message-ID: <1217770113.7231.15.camel@localhost.localdomain> On Sun, 2008-08-03 at 23:23 +1000, David Timms wrote: > Tom "spot" Callaway wrote: > > > > This is exactly why we have ACLs on the guidelines. Unfortunately, it > > also means that people with good intentions who really do find easy-fix > > bugs like these broken links can't just fix it themselves, but IMHO, it > > is a small price to pay. > Is there an easy way to create the fix, but have the wiki store it in a > potential update queue - ie for approval/application ? > That would mean the wiki reviewer get's to be instantly useful, yet not > be able to do unexpected things to the "needing fixes" pages. We'd > probably require a detailed description of the potential change along > with the change itself. Well, the closest thing that I know of is to put something in the "Notes" page for the corresponding item under Packaging/, but its not quite the same. Sounds like an interesting idea for a MediaWiki plugin. ~spot From fedora at leemhuis.info Sun Aug 3 13:48:11 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Aug 2008 15:48:11 +0200 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines In-Reply-To: <1217769149.7231.14.camel@localhost.localdomain> References: <489599A3.1070703@leemhuis.info> <1217769149.7231.14.camel@localhost.localdomain> Message-ID: <4895B71B.10701@leemhuis.info> On 03.08.2008 15:12, Tom "spot" Callaway wrote: > > As an aside, someone recently complained to me that they were unable to > "fix a bug" in the guidelines. When I inquired further, I discovered > that the bug they wanted to fix was not a bug at all, but rather, a > change that would have caused a lot of broken packages if it was > adopted. > > This is exactly why we have ACLs on the guidelines. Sorry, but to me that sounds like a lame excuse. A lot of wikis (including wikipedia) show that the benefits from being open to all heavily outweighs the disadvantage that someone can add something wrong to a page. The guidelines in fact were open in the early Extras days and I'd say they benefited from that a lot. But sure, it happens that someone adds things to a page that are wrong or misleading. No big deal, just manage it wiki style: let two or three people subscribe to the pages in question and let them watch for changes closely. If something bad happens just revert it. Done. Another solution: have two versions -- one locked and one open for editing; then people can enhance the latter easily and all you have to do now and then is to diff the two pages with tools like meld and merge the changes over. Done. Cu knurd From jkeating at redhat.com Sun Aug 3 14:06:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 03 Aug 2008 10:06:36 -0400 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines In-Reply-To: <4895B71B.10701@leemhuis.info> References: <489599A3.1070703@leemhuis.info> <1217769149.7231.14.camel@localhost.localdomain> <4895B71B.10701@leemhuis.info> Message-ID: <1217772396.29433.28.camel@localhost.localdomain> On Sun, 2008-08-03 at 15:48 +0200, Thorsten Leemhuis wrote: > Another solution: have two versions -- one locked and one open for > editing; then people can enhance the latter easily and all you have to > do now and then is to diff the two pages with tools like meld and merge > the changes over. Done. The Discussion tab would be perfect for this, however I'm not sure if mediawiki allows the main page to be locked but the discussion tab to be open. -- 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 opensource at till.name Sun Aug 3 14:49:02 2008 From: opensource at till.name (Till Maas) Date: Sun, 3 Aug 2008 16:49:02 +0200 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines In-Reply-To: <1217770113.7231.15.camel@localhost.localdomain> References: <489599A3.1070703@leemhuis.info> <4895B150.3080902@iinet.net.au> <1217770113.7231.15.camel@localhost.localdomain> Message-ID: <200808031649.21751.opensource@till.name> On Sunday 03 August 2008 15:28:33 Tom "spot" Callaway wrote: > On Sun, 2008-08-03 at 23:23 +1000, David Timms wrote: > > Is there an easy way to create the fix, but have the wiki store it in a > > potential update queue - ie for approval/application ? > > That would mean the wiki reviewer get's to be instantly useful, yet not > > be able to do unexpected things to the "needing fixes" pages. We'd > > probably require a detailed description of the potential change along > > with the change itself. > > Well, the closest thing that I know of is to put something in the > "Notes" page for the corresponding item under Packaging/, but its not > quite the same. > > Sounds like an interesting idea for a MediaWiki plugin. There is the FlaggedRevs extension which allows to mark special revisions as stable: https://fedorahosted.org/fedora-infrastructure/ticket/583 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tibbs at math.uh.edu Sun Aug 3 16:01:29 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Aug 2008 11:01:29 -0500 Subject: [Fedora-packaging] A few links broken in the ReviewGuidelines In-Reply-To: <1217772396.29433.28.camel@localhost.localdomain> References: <489599A3.1070703@leemhuis.info> <1217769149.7231.14.camel@localhost.localdomain> <4895B71B.10701@leemhuis.info> <1217772396.29433.28.camel@localhost.localdomain> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> The Discussion tab would be perfect for this, however I'm not sure JK> if mediawiki allows the main page to be locked but the discussion JK> tab to be open. As far as I know that's how it is set up currently. - J< From dtimms at iinet.net.au Tue Aug 5 15:13:37 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 06 Aug 2008 01:13:37 +1000 Subject: [Fedora-packaging] can Blargg's NTSC libraries be included in fedora ? Message-ID: <48986E21.3080503@iinet.net.au> I am wondering if the following video processing libs could be included in Fedora itself ? nes_ntsc sms_ntsc snes_ntsc These "perform NTSC video signal processing on an image, giving a result similar to that of the game console connected to a TV and unlike that of a simple palette-based image". To do this it would appear to need to understand the hardware chips used in such consoles, but I find no mention of patented or so techniques. For eg: nes_ntsc, in it's current incarnation, require or BR only Fedora packages. An out of Fedora game console emulator could use this library to add 80's realizm to the Emu. The author has released under the LGPL v2.1 or later. Would it be acceptable to be in Fedora ? DaveT. From tcallawa at redhat.com Tue Aug 5 15:22:37 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 05 Aug 2008 11:22:37 -0400 Subject: [Fedora-packaging] can Blargg's NTSC libraries be included in fedora ? In-Reply-To: <48986E21.3080503@iinet.net.au> References: <48986E21.3080503@iinet.net.au> Message-ID: <1217949757.3415.112.camel@localhost.localdomain> On Wed, 2008-08-06 at 01:13 +1000, David Timms wrote: > I am wondering if the following video processing libs could be included > in Fedora itself ? > nes_ntsc > sms_ntsc > snes_ntsc > These "perform NTSC video signal processing on an image, giving a result > similar to that of the game console connected to a TV and unlike that of > a simple palette-based image". To do this it would appear to need to > understand the hardware chips used in such consoles, but I find no > mention of patented or so techniques. > > For eg: nes_ntsc, in it's current incarnation, require or BR only Fedora > packages. An out of Fedora game console emulator could use this library > to add 80's realizm to the Emu. > > The author has released under the LGPL v2.1 or later. Would it be > acceptable to be in Fedora ? I see no reason why not. ~spot From j.w.r.degoede at hhs.nl Tue Aug 5 20:45:43 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 05 Aug 2008 22:45:43 +0200 Subject: [Fedora-packaging] can Blargg's NTSC libraries be included in fedora ? In-Reply-To: <1217949757.3415.112.camel@localhost.localdomain> References: <48986E21.3080503@iinet.net.au> <1217949757.3415.112.camel@localhost.localdomain> Message-ID: <4898BBF7.50308@hhs.nl> Tom "spot" Callaway wrote: > On Wed, 2008-08-06 at 01:13 +1000, David Timms wrote: >> I am wondering if the following video processing libs could be included >> in Fedora itself ? >> nes_ntsc >> sms_ntsc >> snes_ntsc >> These "perform NTSC video signal processing on an image, giving a result >> similar to that of the game console connected to a TV and unlike that of >> a simple palette-based image". To do this it would appear to need to >> understand the hardware chips used in such consoles, but I find no >> mention of patented or so techniques. >> >> For eg: nes_ntsc, in it's current incarnation, require or BR only Fedora >> packages. An out of Fedora game console emulator could use this library >> to add 80's realizm to the Emu. >> >> The author has released under the LGPL v2.1 or later. Would it be >> acceptable to be in Fedora ? > > I see no reason why not. > > ~spot > Well in that case, I would like to say: good idea Dabid, go submit them for review! Regards, Hans From dtimms at iinet.net.au Tue Aug 5 21:51:03 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 06 Aug 2008 07:51:03 +1000 Subject: [Fedora-packaging] can Blargg's NTSC libraries be included in fedora ? In-Reply-To: <4898BBF7.50308@hhs.nl> References: <48986E21.3080503@iinet.net.au> <1217949757.3415.112.camel@localhost.localdomain> <4898BBF7.50308@hhs.nl> Message-ID: <4898CB47.6080606@iinet.net.au> Hans de Goede wrote: > Tom "spot" Callaway wrote: >> On Wed, 2008-08-06 at 01:13 +1000, David Timms wrote: >>> I am wondering if the following video processing libs could be included >>> in Fedora itself ? >>> nes_ntsc >>> sms_ntsc >>> snes_ntsc >>> These "perform NTSC video signal processing on an image, giving a result >>> similar to that of the game console connected to a TV and unlike that of >>> a simple palette-based image". To do this it would appear to need to >>> understand the hardware chips used in such consoles, but I find no >>> mention of patented or so techniques. >>> >>> For eg: nes_ntsc, in it's current incarnation, require or BR only Fedora >>> packages. An out of Fedora game console emulator could use this library >>> to add 80's realizm to the Emu. >>> >>> The author has released under the LGPL v2.1 or later. Would it be >>> acceptable to be in Fedora ? >> >> I see no reason why not. >> >> ~spot >> > > Well in that case, I would like to say: good idea Dabid, go submit them > for review! Tom: Thanks for the quick reply. Hans: It'll take me a few days to get a chance to check them over, thanks for the encouragement ;) DaveT. From ivaxer at gmail.com Wed Aug 6 10:03:42 2008 From: ivaxer at gmail.com (John A. Khvatov) Date: Wed, 6 Aug 2008 14:03:42 +0400 Subject: [Fedora-packaging] Problems with creating gitosis package Message-ID: <20080806100342.GA18340@stingr.net> Hi all, I am trying to create gitosis package, which in fedora wishlist. I have this problems: 1. Gitosis tool require new user with valid shell and without password. System users in guidline UsersAndGroups [1] creates with -s /sbin/nologin option and nothing about valid shell. [1] http://fedoraproject.org/wiki/Packaging/UsersAndGroups 2. This tool goesn't have personal web page and official snapshots. Just git repo http://eagain.net/gitweb/?p=gitosis.git;a=shortlog. May I use post-release package naming for new package? Current spec file for this package: http://stingr.net/git/?p=ivaxer/rpm/gitosis;a=blob_plain;f=gitosis.spec;hb=HEAD How to solve this problems right? Thanks. -- John A. Khvatov From Axel.Thimm at ATrpms.net Wed Aug 6 20:39:19 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Aug 2008 23:39:19 +0300 Subject: [Fedora-packaging] fedora-usermgmt - again Message-ID: <20080806203919.GA26973@victor.nirvana> Hi all, fedora-usermgmt has a period of about a year to appear in discussions, I think the FPC needs to consider it and make a final decision with wich to live with for the next N years. The recent example is that OLPC developers scan the wiki and find fedora-usermgmt promising a lot (which it cannot really devliver) and are lured into using it. Non hard core Fedorians do not know that the authoritative bits are under /Packaging/, and not under for example /PackageUserCreation/ or /PackageUserCreation/ (which are named much too generic for being really fedora-usermgmt pages), and are fooled into thinking that this is Fedora's canonical way to go. Also the few (two?) fedora-usermgmt supporters are pointing people to this direction. Whatever the quality of fedora-usermgmt's approach, we can all agree or disagree or agree on disagreeing, but I think two points are clear: a) it is the FPC's job to dictate how a package should manage its uid/gid requirements. b) the FPC needs to have a uniform method of dealing with it. This means either to ban fedora-usermgmt or to officially embrace it and make it part of the uid/gid assignment process. fedora-usermgmt was grandfathered from fedora.us days and needs to be reviewed just like any other technology we use. Ville and friends did a nice official FPC proposal that passed that catered for all cases where fedora-usermgmt could be used and more (even considering prepopulated uid/gid system resources). It was now in effect since a year os so and we know it does its job. IMHO the next step is to declare fedora-usermgmt as deprecated and request packages to move to a non-fedora-usermgmt uid/gid handling for F11. Most probably all members of the FPC are aware of the recuring fedora-usermgmt discussions - this should not be another one. If you all think you know where you stand, and have read about fedora-usermgmt pros and cons make a quick decision on this to get this over with. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From amdunn at gmail.com Thu Aug 7 17:33:30 2008 From: amdunn at gmail.com (Alan Dunn) Date: Thu, 7 Aug 2008 13:33:30 -0400 Subject: [Fedora-packaging] OCaml library packaging - no-arch for non-devel? Message-ID: Does anyone know whether OCaml library main packages (non-devel packages) should be packaged as no-arch, since they only contain bytecode files, which should be architecture independent? It seems that convention (by looking at the list of available OCaml libraries) is to make them architecture dependent (that is, just have a version for each architecture even though there shouldn't be architecture dependent contents), though rpmlint complains. It seems that Debian's policy (http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt), from which one might've been tempted to draw suggestions, is to include the native code files in the main library package, which is not done for Fedora. (This also doesn't seem to be addressed in the Fedora OCaml packaging guidelines either.) Is this something that just should be done but often isn't, or did I miss something else? - Alan From berrange at redhat.com Thu Aug 7 17:41:11 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 7 Aug 2008 18:41:11 +0100 Subject: [Fedora-packaging] OCaml library packaging - no-arch for non-devel? In-Reply-To: References: Message-ID: <20080807174111.GC24378@redhat.com> On Thu, Aug 07, 2008 at 01:33:30PM -0400, Alan Dunn wrote: > Does anyone know whether OCaml library main packages (non-devel > packages) should be packaged as no-arch, since they only contain > bytecode files, which should be architecture independent? This is incorrect. For common architectures, OCaml generates native machine code - bytecode is only used as a fallback for archs with no native code generator backend. virt-top for example is written in OCaml and is clearly arch dependant: $ file virt-top virt-top: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From rjones at redhat.com Thu Aug 7 17:55:41 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 Aug 2008 18:55:41 +0100 Subject: [Fedora-packaging] OCaml library packaging - no-arch for non-devel? In-Reply-To: References: Message-ID: <20080807175541.GA28888@amd.home.annexia.org> On Thu, Aug 07, 2008 at 01:33:30PM -0400, Alan Dunn wrote: > Does anyone know whether OCaml library main packages (non-devel > packages) should be packaged as no-arch, since they only contain > bytecode files, which should be architecture independent? For the main package in _libraries_ (not programs, obviously) you're right. The only reason we don't do this is that RPM doesn't make it possible to do :-( If you can suggest a way to write a spec file so that the main package is noarch and subpackages are arch-dependent, please let us know. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Thu Aug 7 18:01:57 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 Aug 2008 19:01:57 +0100 Subject: [Fedora-packaging] OCaml library packaging - no-arch for non-devel? In-Reply-To: <20080807174111.GC24378@redhat.com> References: <20080807174111.GC24378@redhat.com> Message-ID: <20080807180157.GB28888@amd.home.annexia.org> On Thu, Aug 07, 2008 at 06:41:11PM +0100, Daniel P. Berrange wrote: > On Thu, Aug 07, 2008 at 01:33:30PM -0400, Alan Dunn wrote: > > Does anyone know whether OCaml library main packages (non-devel > > packages) should be packaged as no-arch, since they only contain > > bytecode files, which should be architecture independent? > > This is incorrect. For common architectures, OCaml generates native > machine code - bytecode is only used as a fallback for archs with no > native code generator backend. > > virt-top for example is written in OCaml and is clearly arch dependant: > > $ file virt-top > virt-top: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped For programs (not libraries) the guidelines are even trickier to write correctly. The current policy is that we should package "best possible binaries", meaning fast native code ones where possible, and falling back to bytecode binaries where we don't have a code generator. So we'd need to make the architecture dependent on that (which is usually determined at rpmbuild time). Note: this is only a theoretical problem in Fedora / RHEL / EPEL because we have native code generators for all platforms, including all the secondary architectures that I'm aware of (PPC64 was a problem for a while, but David Woodhouse wrote a PPC64 back-end for the compiler earlier this year). For Debian it's a real problem because they support some seriously obscure architectures. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 60 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From tcallawa at redhat.com Thu Aug 7 18:05:41 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 07 Aug 2008 14:05:41 -0400 Subject: [Fedora-packaging] OCaml library packaging - no-arch for non-devel? In-Reply-To: <20080807175541.GA28888@amd.home.annexia.org> References: <20080807175541.GA28888@amd.home.annexia.org> Message-ID: <1218132341.7094.18.camel@localhost.localdomain> On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote: > If you can suggest a way to write a spec file so that the main package > is noarch and subpackages are arch-dependent, please let us know. Not really possible without having the buildsystem do multiple passes (like kernel), which we really want to avoid. ~spot From rjones at redhat.com Thu Aug 7 18:35:43 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 7 Aug 2008 19:35:43 +0100 Subject: [Fedora-packaging] OCaml library packaging - no-arch for non-devel? In-Reply-To: <1218132341.7094.18.camel@localhost.localdomain> References: <20080807175541.GA28888@amd.home.annexia.org> <1218132341.7094.18.camel@localhost.localdomain> Message-ID: <20080807183543.GA29026@amd.home.annexia.org> On Thu, Aug 07, 2008 at 02:05:41PM -0400, Tom spot Callaway wrote: > On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote: > > If you can suggest a way to write a spec file so that the main package > > is noarch and subpackages are arch-dependent, please let us know. > > Not really possible without having the buildsystem do multiple passes > (like kernel), which we really want to avoid. That's right, I knew there was another reason for this :-) This all came up when we got the original guidelines approved. I even built bytecode packages of some library on x86 & ppc to prove that the bytecode files really are identical. One way might be to move all the bytecode files into a subpackage (which is noarch) and have the main package (which would now be pretty much empty) 'Require' it. We don't want to break the ability to do 'yum install ocaml-foo ; ocaml ; #require "foo"' 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 Axel.Thimm at ATrpms.net Fri Aug 8 07:00:23 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 8 Aug 2008 10:00:23 +0300 Subject: [Fedora-packaging] Re: OCaml library packaging - no-arch for non-devel? In-Reply-To: <1218132341.7094.18.camel@localhost.localdomain> References: <20080807175541.GA28888@amd.home.annexia.org> <1218132341.7094.18.camel@localhost.localdomain> Message-ID: <20080808070023.GA14896@victor.nirvana> On Thu, Aug 07, 2008 at 02:05:41PM -0400, Tom spot Callaway wrote: > On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote: > > If you can suggest a way to write a spec file so that the main package > > is noarch and subpackages are arch-dependent, please let us know. > > Not really possible without having the buildsystem do multiple passes > (like kernel), which we really want to avoid. Maybe a feature request for rpm 4.7? E.g. BuildArch per %package? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From pmatilai at laiskiainen.org Fri Aug 8 14:19:32 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 8 Aug 2008 17:19:32 +0300 (EEST) Subject: [Fedora-packaging] Re: OCaml library packaging - no-arch for non-devel? In-Reply-To: <20080808070023.GA14896@victor.nirvana> References: <20080807175541.GA28888@amd.home.annexia.org> <1218132341.7094.18.camel@localhost.localdomain> <20080808070023.GA14896@victor.nirvana> Message-ID: On Fri, 8 Aug 2008, Axel Thimm wrote: > On Thu, Aug 07, 2008 at 02:05:41PM -0400, Tom spot Callaway wrote: >> On Thu, 2008-08-07 at 18:55 +0100, Richard W.M. Jones wrote: >>> If you can suggest a way to write a spec file so that the main package >>> is noarch and subpackages are arch-dependent, please let us know. >> >> Not really possible without having the buildsystem do multiple passes >> (like kernel), which we really want to avoid. > > Maybe a feature request for rpm 4.7? E.g. BuildArch per %package? No need to file a separate request, this is one of the top 5 often requested things and priorized to be done "real soon now". - Panu - From vgaburici at gmail.com Fri Aug 8 18:30:28 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 8 Aug 2008 21:30:28 +0300 Subject: [Fedora-packaging] Are there *any* guidelines for what "Group:" an application should go in? Message-ID: Furthermore, are there any guidelines for the creation of new groups? From a.badger at gmail.com Fri Aug 8 18:34:39 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 08 Aug 2008 11:34:39 -0700 Subject: [Fedora-packaging] Are there *any* guidelines for what "Group:" an application should go in? In-Reply-To: References: Message-ID: <489C91BF.5010505@gmail.com> Vasile Gaburici wrote: > Furthermore, are there any guidelines for the creation of new groups? > Pretty much no. We've settled on using comps for grouping of packages rather than the Group: tag. That said, it's probably best to use one of the existing groups (listed in /usr/share/doc/rpm-%{version}/GROUPS -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 vgaburici at gmail.com Fri Aug 8 19:38:18 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 8 Aug 2008 22:38:18 +0300 Subject: [Fedora-packaging] Are there *any* guidelines for what "Group:" an application should go in? In-Reply-To: <489C91BF.5010505@gmail.com> References: <489C91BF.5010505@gmail.com> Message-ID: Thanks for the info. I see it is possible to add a package to multiple comps.xml groups, which is more flexible that what "Group:" can express. Still, it would be nice if anaconda had a search box like PackageKit... On Fri, Aug 8, 2008 at 9:34 PM, Toshio Kuratomi wrote: > Vasile Gaburici wrote: >> >> Furthermore, are there any guidelines for the creation of new groups? >> > Pretty much no. We've settled on using comps for grouping of packages > rather than the Group: tag. That said, it's probably best to use one of the > existing groups (listed in /usr/share/doc/rpm-%{version}/GROUPS > > -Toshio > > From opensource at till.name Sat Aug 9 11:15:37 2008 From: opensource at till.name (Till Maas) Date: Sat, 09 Aug 2008 13:15:37 +0200 Subject: [Fedora-packaging] Extending PatchUpstreamStatus to include other added content (e.g. desktop files) Message-ID: <200808091315.46165.opensource@till.name> Hiyas, I want to propose to extend the following Guideline (given it is one): https://fedoraproject.org/wiki/Packaging/PatchUpstreamStatus Imho it should also include other content that is added to the Package but not a patch, e.g. .desktop files, manpages and icons. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Sat Aug 9 16:41:10 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 09 Aug 2008 18:41:10 +0200 Subject: [Fedora-packaging] Extending PatchUpstreamStatus to include other added content (e.g. desktop files) In-Reply-To: <200808091315.46165.opensource@till.name> References: <200808091315.46165.opensource@till.name> Message-ID: <1218300070.3732.60.camel@beck.corsepiu.local> On Sat, 2008-08-09 at 13:15 +0200, Till Maas wrote: > Hiyas, > > I want to propose to extend the following Guideline (given it is one): > https://fedoraproject.org/wiki/Packaging/PatchUpstreamStatus > > Imho it should also include other content that is added to the Package but not > a patch, e.g. .desktop files, manpages and icons. -1 I don't find this proposal useful, for several reasons: 1. Many patches actually are distribution-specific hacks and not suitable for upstream submission. Upstreams will very unlikely consider them, nor does it make sense to communicate them to upstreams. 2. You are presuming maintainers are actively collaborating/actively participating with an "active upstream". In many cases, this does not apply for one or more reasons. 3. Such "annotations" add bureaucratic bloat. They tend to outdate and rot over longer terms. 4. Maintainers already have the liberty of adding comments/explanations to patches rsp. to specs, rsp. to communicate issues to upstreams. I don't see much sense/use in extending the FPC to "enforce" or "endorse" what I feel is your personal preference, which likely fits into your personal situation. Ralf From vgaburici at gmail.com Sat Aug 9 17:39:18 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sat, 9 Aug 2008 20:39:18 +0300 Subject: [Fedora-packaging] Extending PatchUpstreamStatus to include other added content (e.g. desktop files) In-Reply-To: <1218300070.3732.60.camel@beck.corsepiu.local> References: <200808091315.46165.opensource@till.name> <1218300070.3732.60.camel@beck.corsepiu.local> Message-ID: I agree with Ralf. The packaging guidelines are complex enough already... On Sat, Aug 9, 2008 at 7:41 PM, Ralf Corsepius wrote: > On Sat, 2008-08-09 at 13:15 +0200, Till Maas wrote: >> Hiyas, >> >> I want to propose to extend the following Guideline (given it is one): >> https://fedoraproject.org/wiki/Packaging/PatchUpstreamStatus >> >> Imho it should also include other content that is added to the Package but not >> a patch, e.g. .desktop files, manpages and icons. > -1 > > I don't find this proposal useful, for several reasons: > > 1. Many patches actually are distribution-specific hacks and not > suitable for upstream submission. Upstreams will very unlikely consider > them, nor does it make sense to communicate them to upstreams. > > 2. You are presuming maintainers are actively collaborating/actively > participating with an "active upstream". In many cases, this does not > apply for one or more reasons. > > 3. Such "annotations" add bureaucratic bloat. They tend to outdate and > rot over longer terms. > > 4. Maintainers already have the liberty of adding comments/explanations > to patches rsp. to specs, rsp. to communicate issues to upstreams. > I don't see much sense/use in extending the FPC to "enforce" or > "endorse" what I feel is your personal preference, which likely fits > into your personal situation. > > Ralf > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From vgaburici at gmail.com Tue Aug 12 04:48:30 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Tue, 12 Aug 2008 07:48:30 +0300 Subject: [Fedora-packaging] Best way to add a line to a config file from another package? Message-ID: I need to add line to /usr/share/texmf/dvips/config/config.ps to get some extra functionality enabled for lcdf-typetools, namely Type 42 support. The config.ps file is properly marked as a config file in texlive-texmf-dvips. Is there some infrastructure that's normally used to hack config files or should I just echo "..." >> config.ps? From pertusus at free.fr Tue Aug 12 16:33:55 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 12 Aug 2008 18:33:55 +0200 Subject: [Fedora-packaging] Best way to add a line to a config file from another package? In-Reply-To: References: Message-ID: <20080812163355.GB29797@free.fr> On Tue, Aug 12, 2008 at 07:48:30AM +0300, Vasile Gaburici wrote: > I need to add line to /usr/share/texmf/dvips/config/config.ps to get > some extra functionality enabled for lcdf-typetools, namely Type 42 > support. The config.ps file is properly marked as a config file in > texlive-texmf-dvips. Is there some infrastructure that's normally used > to hack config files or should I just echo "..." >> config.ps? I think that it is improperly marked as %config. It should not be touched upon by the user, and should be solely under the upstream or packagers control. It should be, in my opinion, marked as %ghost %verify(not size mtime md5) That being said you are entitled to change that file as a packager in a post-install script, however * you should make sure that the change is reverted if your package is removed. * you should be very very careful, since this kind of change can easily mess the system. It should be safe to be applied whatever the order of package install (as constrained by the Requires), and it should not output anything except in very rare cases. Also if the change can be left in the file, it would even be better to patch it in telive-texmf. -- Pat From vgaburici at gmail.com Tue Aug 12 17:09:04 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Tue, 12 Aug 2008 20:09:04 +0300 Subject: [Fedora-packaging] Best way to add a line to a config file from another package? In-Reply-To: <20080812163355.GB29797@free.fr> References: <20080812163355.GB29797@free.fr> Message-ID: No, it's actually a proper system-wide config file. I've edited my local config.ps successfully to enable Type 42 fonts by adding an additional map. Now I want to be able to do that system-wide when lcdf-typetools is installed. I've written a patch for otftotfm (and sent it upstream) that allows installation of Type 42 fonts from TrueType fonts. Type 42 fonts can be embedded in PostScript files, so PK fonts generation is no longer required when TT fonts are used with dvips. This lets Fedora users embed fonts like Liberation as outlines in TeX/dvips PostScript output. There's been a discussion on the font list about this a while back, or more precisely about the lack of such an automated tool. On Tue, Aug 12, 2008 at 7:33 PM, Patrice Dumas wrote: > On Tue, Aug 12, 2008 at 07:48:30AM +0300, Vasile Gaburici wrote: >> I need to add line to /usr/share/texmf/dvips/config/config.ps to get >> some extra functionality enabled for lcdf-typetools, namely Type 42 >> support. The config.ps file is properly marked as a config file in >> texlive-texmf-dvips. Is there some infrastructure that's normally used >> to hack config files or should I just echo "..." >> config.ps? > > I think that it is improperly marked as %config. It should not be > touched upon by the user, and should be solely under the upstream or > packagers control. It should be, in my opinion, marked as > %ghost %verify(not size mtime md5) > > That being said you are entitled to change that file as a packager > in a post-install script, however > * you should make sure that the change is reverted if your package is > removed. > * you should be very very careful, since this kind of change can > easily mess the system. It should be safe to be applied whatever > the order of package install (as constrained by the Requires), > and it should not output anything except in very rare cases. > > Also if the change can be left in the file, it would even be better > to patch it in telive-texmf. > > -- > Pat > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From vgaburici at gmail.com Tue Aug 12 17:20:18 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Tue, 12 Aug 2008 20:20:18 +0300 Subject: [Fedora-packaging] Best way to add a line to a config file from another package? In-Reply-To: References: <20080812163355.GB29797@free.fr> Message-ID: Also, removing the entry is not necessary. Nothing breaks if the extra map does not exist. It would actually be a bad idea to remove the entry because Type 42 fonts generated by the user using otftotfm would become unusable after the tool is uninstalled, even thought the tool is not required to use the fonts it generated. Given this, I'll submit a config patch for texlive-texmf-dvips. But first I need someone to review the lcdf-typetools package because it has been orphaned for a while, so it's not in Fedora anymore. I have not yet put up the patched version, although I'm using it, because of this config issue. The tool is useful enough for installing fonts for TeX as it is. Well, it is actually required to fix a bug I filed against texlive-context... On Tue, Aug 12, 2008 at 8:09 PM, Vasile Gaburici wrote: > No, it's actually a proper system-wide config file. I've edited my > local config.ps successfully to enable Type 42 fonts by adding an > additional map. Now I want to be able to do that system-wide when > lcdf-typetools is installed. > > I've written a patch for otftotfm (and sent it upstream) that allows > installation of Type 42 fonts from TrueType fonts. Type 42 fonts can > be embedded in PostScript files, so PK fonts generation is no longer > required when TT fonts are used with dvips. This lets Fedora users > embed fonts like Liberation as outlines in TeX/dvips PostScript > output. There's been a discussion on the font list about this a while > back, or more precisely about the lack of such an automated tool. > > On Tue, Aug 12, 2008 at 7:33 PM, Patrice Dumas wrote: >> On Tue, Aug 12, 2008 at 07:48:30AM +0300, Vasile Gaburici wrote: >>> I need to add line to /usr/share/texmf/dvips/config/config.ps to get >>> some extra functionality enabled for lcdf-typetools, namely Type 42 >>> support. The config.ps file is properly marked as a config file in >>> texlive-texmf-dvips. Is there some infrastructure that's normally used >>> to hack config files or should I just echo "..." >> config.ps? >> >> I think that it is improperly marked as %config. It should not be >> touched upon by the user, and should be solely under the upstream or >> packagers control. It should be, in my opinion, marked as >> %ghost %verify(not size mtime md5) >> >> That being said you are entitled to change that file as a packager >> in a post-install script, however >> * you should make sure that the change is reverted if your package is >> removed. >> * you should be very very careful, since this kind of change can >> easily mess the system. It should be safe to be applied whatever >> the order of package install (as constrained by the Requires), >> and it should not output anything except in very rare cases. >> >> Also if the change can be left in the file, it would even be better >> to patch it in telive-texmf. >> >> -- >> Pat >> >> -- >> Fedora-packaging mailing list >> Fedora-packaging at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-packaging >> >> > From Axel.Thimm at ATrpms.net Tue Aug 12 20:12:13 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 12 Aug 2008 23:12:13 +0300 Subject: [Fedora-packaging] Re: Best way to add a line to a config file from another package? In-Reply-To: References: <20080812163355.GB29797@free.fr> Message-ID: <20080812201213.GB13932@victor.nirvana> On Tue, Aug 12, 2008 at 08:20:18PM +0300, Vasile Gaburici wrote: > Also, removing the entry is not necessary. Nothing breaks if the extra > map does not exist. It would actually be a bad idea to remove the > entry because Type 42 fonts generated by the user using otftotfm would > become unusable after the tool is uninstalled, even thought the tool > is not required to use the fonts it generated. Given this, I'll submit > a config patch for texlive-texmf-dvips. Ideally this sounds like something that should (also) be submitted upstream. If it's a change that people can only benefit from and doesn't stand in the way of upstream's future plans, upstream will accept it. Otherwise maybe upstream will even point out a flaw (not compatible with future upstream planned changes, different solution in works etc.). And if upstream signals green light for such a change the maintainer of the texlive packages will be easier to convince to allow for a patch. > > I've written a patch for otftotfm (and sent it upstream) that allows > > installation of Type 42 fonts from TrueType fonts. Patching config.ps and this patch should go hand in hand in both upstream and Fedora packaging. E.g. if the patch to otftotfm were to be rejected upstream with sane reasoning, then we shouldn't deviate. Sounds very interesting, I hope this goes through! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rnorwood at redhat.com Tue Aug 12 21:26:25 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 12 Aug 2008 17:26:25 -0400 Subject: [Fedora-packaging] Simple cvs extras suggestion Message-ID: <20080812172625.12e521ea@solitude.devel.redhat.com> Hi, With the goal of opening up ACLs on 'most' packages, I'd like to suggest that the New Package CVS Request template on this page: https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure Change the last line from: Cvsextras Commits: To: Cvsextras Commits: yes Since the whole point of the template is for people to cut and paste it, this will make 'yes', truly the default option. Also, the text could be changed to be more descriptive. Something like 'Other Fedora members can commit' or change it around to 'Restrict commit access'. Sure, the user should read the documentation half a page down and choose 'yes', but how many people don't? And, more to the point, the term 'cvsextras' isn't really defined anywhere on the page. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From a.badger at gmail.com Tue Aug 12 21:42:49 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 12 Aug 2008 14:42:49 -0700 Subject: [Fedora-packaging] Simple cvs extras suggestion In-Reply-To: <20080812172625.12e521ea@solitude.devel.redhat.com> References: <20080812172625.12e521ea@solitude.devel.redhat.com> Message-ID: <48A203D9.80105@gmail.com> Robin Norwood wrote: > Hi, > > With the goal of opening up ACLs on 'most' packages, I'd like to > suggest that the New Package CVS Request template on this page: > > https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > Change the last line from: > > Cvsextras Commits: > > To: > > Cvsextras Commits: yes > > > Since the whole point of the template is for people to cut and paste > it, this will make 'yes', truly the default option. > > Also, the text could be changed to be more descriptive. Something like > 'Other Fedora members can commit' or change it around to 'Restrict > commit access'. > > Sure, the user should read the documentation half a page down and > choose 'yes', but how many people don't? And, more to the point, the > term 'cvsextras' isn't really defined anywhere on the page. > We're actually thinking of removing that option altogether and letting people who are paranoid update the acls in the pkgdb before they import any code. Otherwise, the idea of changing things around sounds right on the mark :-) BTW, we should have discussions like this on fedora-devel I think. packaging is for discussions of guidelines and so it won't reach as wide an audience. -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 abartlet at samba.org Tue Aug 12 23:39:39 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 13 Aug 2008 09:39:39 +1000 Subject: [Fedora-packaging] Advise on the Samba4/OpenChange stack Message-ID: <1218584379.3887.20.camel@naomi.s4.naomi.abartlet.net> I've been trying to package the OpenChange stack (OpenChange, Samba4 and Heimdal) for Fedora, and I'm between a rock and a hard place on the packaging of Heimdal (Samba's choice of Kerberos infrastructure). I can either include it in Samba4 (as we do upstream), and break the 'no included libraries' rule, or I can propose Heimdal as a package, and conflict with krb5-devel and krb5-debuginfo. Similarly, the non-library parts of Samba4 do conflict with Samba3. (but I'm happy to simply not provide those parts of the package, if it comes to it). Does anybody have any suggestions about the best way forward? The reviews are at: https://bugzilla.redhat.com/show_bug.cgi?id=452212 https://bugzilla.redhat.com/show_bug.cgi?id=453083 https://bugzilla.redhat.com/show_bug.cgi?id=453395 Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From vgaburici at gmail.com Wed Aug 13 01:26:00 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Wed, 13 Aug 2008 04:26:00 +0300 Subject: [Fedora-packaging] Re: Best way to add a line to a config file from another package? In-Reply-To: <20080812201213.GB13932@victor.nirvana> References: <20080812163355.GB29797@free.fr> <20080812201213.GB13932@victor.nirvana> Message-ID: Well, changing the default configuration file is not necessarily something that dvips developers need to hear about. The original config.ps file has section saying: % This shows how to add your own map file. % Remove the comment and adjust the name: % p +myfonts.map On the other hand, this extra psfonts_t42.map configuration file I'm adding is in a way a workaround for the current behavior of updmap, which puts ".ttf" entries in both psfonts_t1.map and psfonts_pk.map, even though that practically means dvips will use bitmaps for ttfs regardless whether you enabled dvipsPreferOutline, which defaults to on. I'm not the first person to be annoyed by this. There's been a long thread on tex.fonts about this a couple of year back [http://osdir.com/ml/tex.fonts/2006-08/msg00017.html], but nobody changed anything... However, if one were to change updmap to add ".t42" entries instead of ".ttf" to psfonts_t1.map instead of my solution of using an additional map, then one needs to make sure that the TeX distro ships t42 counterparts for all ttf fonts it ships because there is no fallback for dvips anymore if dvipsPreferOutline is enabled. And there are some ttf fonts shipped with TeXLive, but obviously no t42 versions. A more elegant solution would be for dvips itself to encapsulate TTF fonts in Type 42 as needed, but I don't know how easy is that to hack, especially since dvips has no notion of dvipsPreferOutline; the desired behavior is obtained by updmap symlinking psfonts.map to either psfonts_t1.map or psfonts_pk.map. The teTeX fokes, which intially wrote updmap, seem to have preferred this hack instead of changing dvips... It's not clear if dvips is even supported/maitained anymore by Radical Eye. Their web page [http://www.radicaleye.com/dvips.html] says "To get the latest version of dvips, simply get the latest version of teTeX or some other TeX distribution that includes dvips. [...] I no longer support installation of dvips independent of full installation of a TeX distribution." So, presumably we'd have to send the patch to TeXLive. Adding an additional map seemed a lot simpler than dealing with this mess... On Tue, Aug 12, 2008 at 11:12 PM, Axel Thimm wrote: > On Tue, Aug 12, 2008 at 08:20:18PM +0300, Vasile Gaburici wrote: >> Also, removing the entry is not necessary. Nothing breaks if the extra >> map does not exist. It would actually be a bad idea to remove the >> entry because Type 42 fonts generated by the user using otftotfm would >> become unusable after the tool is uninstalled, even thought the tool >> is not required to use the fonts it generated. Given this, I'll submit >> a config patch for texlive-texmf-dvips. > > Ideally this sounds like something that should (also) be submitted > upstream. If it's a change that people can only benefit from and > doesn't stand in the way of upstream's future plans, upstream will > accept it. Otherwise maybe upstream will even point out a flaw (not > compatible with future upstream planned changes, different solution in > works etc.). > > And if upstream signals green light for such a change the maintainer > of the texlive packages will be easier to convince to allow for a > patch. > >> > I've written a patch for otftotfm (and sent it upstream) that allows >> > installation of Type 42 fonts from TrueType fonts. > > Patching config.ps and this patch should go hand in hand in both > upstream and Fedora packaging. E.g. if the patch to otftotfm were to > be rejected upstream with sane reasoning, then we shouldn't deviate. > > Sounds very interesting, I hope this goes through! > -- > Axel.Thimm at ATrpms.net > From pertusus at free.fr Wed Aug 13 14:10:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 13 Aug 2008 16:10:20 +0200 Subject: [Fedora-packaging] Best way to add a line to a config file from another package? In-Reply-To: References: <20080812163355.GB29797@free.fr> Message-ID: <20080813141020.GA3905@free.fr> On Tue, Aug 12, 2008 at 08:09:04PM +0300, Vasile Gaburici wrote: > No, it's actually a proper system-wide config file. I've edited my > local config.ps successfully to enable Type 42 fonts by adding an > additional map. Now I want to be able to do that system-wide when > lcdf-typetools is installed. It is, of course, a proper system-wide config file. But in my opinion it should be overwritten by what upstream/packagers give, and user changes should not be kept. If a user wants to have his changes kept, he should copy the file to /etc/texmf/web2c/, his file will be used in priority. -- Pat From pertusus at free.fr Wed Aug 13 14:17:04 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 13 Aug 2008 16:17:04 +0200 Subject: [Fedora-packaging] Re: Best way to add a line to a config file from another package? In-Reply-To: References: <20080812163355.GB29797@free.fr> <20080812201213.GB13932@victor.nirvana> Message-ID: <20080813141704.GB3905@free.fr> On Wed, Aug 13, 2008 at 04:26:00AM +0300, Vasile Gaburici wrote: > Well, changing the default configuration file is not necessarily > something that dvips developers need to hear about. The original > config.ps file has section saying: > % This shows how to add your own map file. > % Remove the comment and adjust the name: > % p +myfonts.map I may be missing something, but it seems to me that we shouldn't hardcode map files in here, but instead use updmap. > However, if one were to change updmap to add ".t42" entries instead of > ".ttf" to psfonts_t1.map instead of my solution of using an additional > map, then one needs to make sure that the TeX distro ships t42 > counterparts for all ttf fonts it ships because there is no fallback > for dvips anymore if dvipsPreferOutline is enabled. And there are some > ttf fonts shipped with TeXLive, but obviously no t42 versions. What about generating t42 versions, or have them in a package that dvips depends on (on fedora...)? And then patch updamap to use t42 fonts in priority over ttf fonts? > It's not clear if dvips is even supported/maitained anymore by Radical > Eye. Their web page [http://www.radicaleye.com/dvips.html] says "To > get the latest version of dvips, simply get the latest version of > teTeX or some other TeX distribution that includes dvips. [...] I no > longer support installation of dvips independent of full installation > of a TeX distribution." So, presumably we'd have to send the patch to > TeXLive. Adding an additional map seemed a lot simpler than dealing > with this mess... It indeed seems that dvips is maintained by texlive folks, at least that's the conclusion I came to when looking at what should come from texlive or not. -- Pat From loupgaroublond at gmail.com Wed Aug 13 15:01:16 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 13 Aug 2008 17:01:16 +0200 Subject: [Fedora-packaging] Revised Haskell Guidelines 2008.08.13 Message-ID: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> Hi Lists, I've revised the guidelines once again to cover the issues brought up when I brought them before the packaging committee. As follows is a list of the issues I've heard, and how they are fixed. * %buildsubdir is not a common way of doing things ** we need this macro in the install phase to get at the working dir we used to compile the package. This was only needed by the rather scary looking file seeking code, so I put it into a macro that is called by another macro, and hid it from public view. The user should not need this in the spec file anymore. * this looks scary, use macros ** done, the guidelines include them * how do runtime requirements work, vis a vis build time, etc... ** GHC apparently uses static linking for haskell libraries and dynamic for C libraries. *** This is quite similar to OCaml ** all the dynamic links to C libraries can be automagically detected by RPM's wonderful automagic. ** the -devel packages still need to be put in by hand in the BuildRequires ** most packages only need their dependency libraries at build time. ** Some packages, notably xmonad, do code generation and require the dependencies at run time. *** the packager is responsible for tracking this bit * this file detection stuff is scary ** I've put it into a series of macros and documented it * this register stuff looks kinky ** for starters, it's needed so the compiler knows where to look for certain packages ** it's been converted to a bunch of macros I also think that if we can make this any more simple, then the only thing that cabal-rpm really really needs to do is detect if a package is a library, binary, or both, and then fill in some of the dependencies automatically, whcih it's not clever enough yet to do properly anyways. We may just need to create a few rpm templates, and be done with it. Anyways, I present the guidelines once more for review. I will try to comandeer the help of the people in the SIG to start putting together a repo of packages using these macros. The deadeline for the F10 feature is coming up soon, and I want to have it in a relatively stable shape, even though we have time to fine tune the details later. -Yaakov From a.badger at gmail.com Wed Aug 13 16:20:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 13 Aug 2008 09:20:59 -0700 Subject: [Fedora-packaging] Advise on the Samba4/OpenChange stack In-Reply-To: <1218584379.3887.20.camel@naomi.s4.naomi.abartlet.net> References: <1218584379.3887.20.camel@naomi.s4.naomi.abartlet.net> Message-ID: <48A309EB.4010600@gmail.com> Andrew Bartlett wrote: > I've been trying to package the OpenChange stack (OpenChange, Samba4 and > Heimdal) for Fedora, and I'm between a rock and a hard place on the > packaging of Heimdal (Samba's choice of Kerberos infrastructure). I can > either include it in Samba4 (as we do upstream), and break the 'no > included libraries' rule, or I can propose Heimdal as a package, and > conflict with krb5-devel and krb5-debuginfo. > Separate library packages. If it's just the -devel that's an issue, placing Heimdal's headers in a subdirectory that samba4 can access by using a -I/usr/include/heimdal, for instance, would work. > Similarly, the non-library parts of Samba4 do conflict with Samba3. > (but I'm happy to simply not provide those parts of the package, if it > comes to it). > Are Samba3 and Samba4 commandline compatible for these? If so it's possible that alternatives is what we want to use here. These are the criteria: 1) command line compatible 2) app that the sysadmin should deal with, not end users. -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 vgaburici at gmail.com Wed Aug 13 17:09:13 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Wed, 13 Aug 2008 20:09:13 +0300 Subject: [Fedora-packaging] Re: Best way to add a line to a config file from another package? In-Reply-To: <20080813141704.GB3905@free.fr> References: <20080812163355.GB29797@free.fr> <20080812201213.GB13932@victor.nirvana> <20080813141704.GB3905@free.fr> Message-ID: On Wed, Aug 13, 2008 at 5:17 PM, Patrice Dumas wrote: > On Wed, Aug 13, 2008 at 04:26:00AM +0300, Vasile Gaburici wrote: >> Well, changing the default configuration file is not necessarily >> something that dvips developers need to hear about. The original >> config.ps file has section saying: >> % This shows how to add your own map file. >> % Remove the comment and adjust the name: >> % p +myfonts.map > > I may be missing something, but it seems to me that we shouldn't > hardcode map files in here, but instead use updmap. Yes, you are missing something. By default dvips uses a single map called psfonts.map[*]. What updmap esentially does is is to keep that in sync with 2 other maps (for pdftex and dvipdfm), starting from a single source: updmap.cfg. But if we add type 42 fonts, we *don't* want pdftex and dvipdfm map files to have the same entries as dvips. So using an additional map for dvips, which overrides some entries in the one generated by updmap, is reasonable. [*] I've glossed over the fact that there are two files psfonts_t1.map and psfonts_pk.map, but only one is read via a symlink. The symlink is changed by updmap depending on whether you set dvipsPreferOutline to true or false. Before my patch, otftotfm alrady installs it's own map, called lcdftools.map, which serves as the master source map for the fonts it has installed. It adds this map to updmap.cfg, so when updmap runs, it basically copies any entries in lcdftools.map to the 3 maps (dvips, pdftex, dvipdfm). With my patch, otftoftm also creates a map called psfonts_t42.map, in which it puts any t42 entries for the fonts it has installed. Except that you don't need to run updmap to blast these entries to dvips because it reads it directly (thanks to config.ps). It's okay not to spread any of these t42 entries to other maps because no other program can read those fonts. Actually, if you put a t42 font entry in pdftex's map, it won't load the font at all. I know this a bit hard to follow. I'll update the src rpm so you can test this. I'm not adding any scriptlet for now, but I'll put instructions for changing your user's config.ps in README.fedora. >> However, if one were to change updmap to add ".t42" entries instead of >> ".ttf" to psfonts_t1.map instead of my solution of using an additional >> map, then one needs to make sure that the TeX distro ships t42 >> counterparts for all ttf fonts it ships because there is no fallback >> for dvips anymore if dvipsPreferOutline is enabled. And there are some >> ttf fonts shipped with TeXLive, but obviously no t42 versions. > > What about generating t42 versions, or have them in a package that dvips > depends on (on fedora...)? And then patch updamap to use t42 fonts in > priority over ttf fonts? That was actually my first idea before I discovered that dvips can read multiple maps by itself. It seems simpler, but it is far harder to make work properly. If updmap automatically wrote t42 entries instead of ttf entries into a single dvips map, then you'd have to guarantee somehow that every ttf font has a t42 counterpart. Which is not easy, because updmap is designed as "dumb" file synchronization tool, not a font installer. Basically, it would have to check if the t42 file exists, if not it would have to call otftotfm, which essentially the reverse of how things are layered now, i.e. otftotfm invokes updmap after all the required font files have been generated. Updmap wansn't meant to do any of that. I doubt upstream would ever accept the mission creep and significant changes in updmap that would enatail. >> It's not clear if dvips is even supported/maitained anymore by Radical >> Eye. Their web page [http://www.radicaleye.com/dvips.html] says "To >> get the latest version of dvips, simply get the latest version of >> teTeX or some other TeX distribution that includes dvips. [...] I no >> longer support installation of dvips independent of full installation >> of a TeX distribution." So, presumably we'd have to send the patch to >> TeXLive. Adding an additional map seemed a lot simpler than dealing >> with this mess... > > It indeed seems that dvips is maintained by texlive folks, at least > that's the conclusion I came to when looking at what should come from > texlive or not. > > -- > Pat > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From opensource at till.name Wed Aug 13 19:28:06 2008 From: opensource at till.name (Till Maas) Date: Wed, 13 Aug 2008 21:28:06 +0200 Subject: [Fedora-packaging] Simple cvs extras suggestion In-Reply-To: <20080812172625.12e521ea@solitude.devel.redhat.com> References: <20080812172625.12e521ea@solitude.devel.redhat.com> Message-ID: <200808132128.16055.opensource@till.name> On Tue August 12 2008, Robin Norwood wrote: > Hi, > > With the goal of opening up ACLs on 'most' packages, I'd like to > suggest that the New Package CVS Request template on this page: > > https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > Change the last line from: > > Cvsextras Commits: > > To: > > Cvsextras Commits: yes Afaik the group is now called packager, therefore it probably be | Packager Commits: yes Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tibbs at math.uh.edu Wed Aug 13 19:44:57 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Aug 2008 14:44:57 -0500 Subject: [Fedora-packaging] Simple cvs extras suggestion In-Reply-To: <20080812172625.12e521ea@solitude.devel.redhat.com> References: <20080812172625.12e521ea@solitude.devel.redhat.com> Message-ID: >>>>> "RN" == Robin Norwood writes: RN> Hi, With the goal of opening up ACLs on 'most' packages, I'd like RN> to suggest that the New Package CVS Request template on this page: I went ahead and made that change, but then I realize that this is all going to change yet again when the uberpackager stuff gets turned on. - J< From green at redhat.com Wed Aug 13 23:15:34 2008 From: green at redhat.com (Anthony Green) Date: Wed, 13 Aug 2008 16:15:34 -0700 Subject: [Fedora-packaging] Next meeting? Message-ID: <48A36B16.5000802@redhat.com> When is the next packaging meeting? According to the minutes page, there hasn't been a meeting in over two months, but prior to that there were two or three meetings a month. I'm mainly interested in getting approval for my Lisp packaging guidelines. Thanks, AG From tibbs at math.uh.edu Wed Aug 13 23:17:51 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Aug 2008 18:17:51 -0500 Subject: [Fedora-packaging] Next meeting? In-Reply-To: <48A36B16.5000802@redhat.com> References: <48A36B16.5000802@redhat.com> Message-ID: >>>>> "AG" == Anthony Green writes: AG> When is the next packaging meeting? According to the minutes AG> page, there hasn't been a meeting in over two months, but prior to AG> that there were two or three meetings a month. It has been terribly difficult to achieve quorum given vacations and such. (I was away for nearly a month, for example.) We have been voting via email and I suspect that will continue for a while. - J< From abartlet at samba.org Thu Aug 14 03:09:47 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 14 Aug 2008 13:09:47 +1000 Subject: [Fedora-packaging] Advise on the Samba4/OpenChange stack In-Reply-To: <48A309EB.4010600@gmail.com> References: <1218584379.3887.20.camel@naomi.s4.naomi.abartlet.net> <48A309EB.4010600@gmail.com> Message-ID: <1218683387.4094.5.camel@ruth> On Wed, 2008-08-13 at 09:20 -0700, Toshio Kuratomi wrote: > Andrew Bartlett wrote: > > I've been trying to package the OpenChange stack (OpenChange, Samba4 and > > Heimdal) for Fedora, and I'm between a rock and a hard place on the > > packaging of Heimdal (Samba's choice of Kerberos infrastructure). I can > > either include it in Samba4 (as we do upstream), and break the 'no > > included libraries' rule, or I can propose Heimdal as a package, and > > conflict with krb5-devel and krb5-debuginfo. > > > Separate library packages. If it's just the -devel that's an issue, > placing Heimdal's headers in a subdirectory that samba4 can access by > using a -I/usr/include/heimdal, for instance, would work. Sadly it does not in reality. Having more than one kerberos distribution's headers installed has been known to cause major pain, even if the headers can be nominally separated. > > Similarly, the non-library parts of Samba4 do conflict with Samba3. > > (but I'm happy to simply not provide those parts of the package, if it > > comes to it). > > > Are Samba3 and Samba4 commandline compatible for these? If so it's > possible that alternatives is what we want to use here. These are the > criteria: > > 1) command line compatible > 2) app that the sysadmin should deal with, not end users. No, they are not compatible. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Aug 14 15:32:15 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 14 Aug 2008 17:32:15 +0200 Subject: [Fedora-packaging] Simple cvs extras suggestion In-Reply-To: References: <20080812172625.12e521ea@solitude.devel.redhat.com> Message-ID: <20080814153215.GF2646@free.fr> On Wed, Aug 13, 2008 at 02:44:57PM -0500, Jason L Tibbitts III wrote: > >>>>> "RN" == Robin Norwood writes: > > RN> Hi, With the goal of opening up ACLs on 'most' packages, I'd like > RN> to suggest that the New Package CVS Request template on this page: > > I went ahead and made that change, but then I realize that this is all > going to change yet again when the uberpackager stuff gets turned on. This mysterious) word has already appeared on the sponsorship messages, so maybe it is already turned on? -- Pat From tibbs at math.uh.edu Thu Aug 14 15:35:11 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Aug 2008 10:35:11 -0500 Subject: [Fedora-packaging] Simple cvs extras suggestion In-Reply-To: <20080814153215.GF2646@free.fr> References: <20080812172625.12e521ea@solitude.devel.redhat.com> <20080814153215.GF2646@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> This mysterious) word has already appeared on the sponsorship PD> messages, so maybe it is already turned on? It is not turned on yet. - J< From dtimms at iinet.net.au Thu Aug 14 22:11:11 2008 From: dtimms at iinet.net.au (David Timms) Date: Fri, 15 Aug 2008 08:11:11 +1000 Subject: [Fedora-packaging] resolving rpmlint absolute symlinks issue Message-ID: <48A4AD7F.5000001@iinet.net.au> I am getting the following with a package I'm working on: $ rpmlint --info RPMS/noarch/pyvnc2swf-0.9.3-3.fc9.noarch.rpm pyvnc2swf.noarch: W: symlink-should-be-relative /usr/bin/vnc2swf /usr/lib/python2.5/site-packages/pyvnc2swf/vnc2swf.py Absolute symlinks are problematic eg. when working with chroot environments. pyvnc2swf.noarch: W: symlink-should-be-relative /usr/bin/vnc2swf-edit /usr/lib/python2.5/site-packages/pyvnc2swf/edit.py Absolute symlinks are problematic eg. when working with chroot environments. 1 packages and 0 specfiles checked; 0 errors, 2 warnings. I did a bit of a search on absolute symlinks, and tried to make such using symlinks -cs: http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/25 , but that didn't resolve the rpm warning. Do you know if this is considered normal to ignore, or can you point to a way to resolve it ? [https://bugzilla.redhat.com/show_bug.cgi?id=448201] DaveT. From tcallawa at redhat.com Fri Aug 15 04:03:17 2008 From: tcallawa at redhat.com (Tom spot Callaway) Date: Fri, 15 Aug 2008 00:03:17 -0400 Subject: [Fedora-packaging] resolving rpmlint absolute symlinks issue In-Reply-To: <48A4AD7F.5000001@iinet.net.au> References: <48A4AD7F.5000001@iinet.net.au> Message-ID: <20080815000317.c86621a7.tcallawa@redhat.com> On Fri, 15 Aug 2008 08:11:11 +1000 David Timms wrote: > I am getting the following with a package I'm working on: > > $ rpmlint --info RPMS/noarch/pyvnc2swf-0.9.3-3.fc9.noarch.rpm > pyvnc2swf.noarch: W: symlink-should-be-relative /usr/bin/vnc2swf > /usr/lib/python2.5/site-packages/pyvnc2swf/vnc2swf.py > Absolute symlinks are problematic eg. when working with chroot environments. > > pyvnc2swf.noarch: W: symlink-should-be-relative /usr/bin/vnc2swf-edit > > Absolute symlinks are problematic eg. when working with chroot environments. You resolve these like this: Instead of doing: ln -s /usr/lib/python2.5/site-packages/pyvnc2swf/edit.py /usr/bin/vnc2swf-edit You do a relative link, like this: cd /usr/lib/python2.5/site-packages/pyvnc2swf/ ln -s edit.py ../../../../bin/vnc2swf-edit hth, ~spot -- Tom "spot" Callaway From dtimms at iinet.net.au Fri Aug 15 14:26:25 2008 From: dtimms at iinet.net.au (David Timms) Date: Sat, 16 Aug 2008 00:26:25 +1000 Subject: [Fedora-packaging] resolving rpmlint absolute symlinks issue In-Reply-To: <20080815000317.c86621a7.tcallawa@redhat.com> References: <48A4AD7F.5000001@iinet.net.au> <20080815000317.c86621a7.tcallawa@redhat.com> Message-ID: <48A59211.5010805@iinet.net.au> Tom spot Callaway wrote: > On Fri, 15 Aug 2008 08:11:11 +1000 ... > You do a relative link, like this: > > cd /usr/lib/python2.5/site-packages/pyvnc2swf/ > ln -s edit.py ../../../../bin/vnc2swf-edit Actually, http://www.redhat.com/archives/fedora-devel-list/2008-June/msg01188.html suggests that it will be flagged as a warning unless it's a .so in certain locations. Should the warning be ignored in my case ? DaveT. From Axel.Thimm at ATrpms.net Sat Aug 16 14:23:56 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 16 Aug 2008 17:23:56 +0300 Subject: [Fedora-packaging] Re: resolving rpmlint absolute symlinks issue In-Reply-To: <48A59211.5010805@iinet.net.au> References: <48A4AD7F.5000001@iinet.net.au> <20080815000317.c86621a7.tcallawa@redhat.com> <48A59211.5010805@iinet.net.au> Message-ID: <20080816142356.GA25158@victor.nirvana> On Sat, Aug 16, 2008 at 12:26:25AM +1000, David Timms wrote: > Tom spot Callaway wrote: > > On Fri, 15 Aug 2008 08:11:11 +1000 > ... > > You do a relative link, like this: > > > > cd /usr/lib/python2.5/site-packages/pyvnc2swf/ > > ln -s edit.py ../../../../bin/vnc2swf-edit > > Actually, > http://www.redhat.com/archives/fedora-devel-list/2008-June/msg01188.html > suggests that it will be flagged as a warning unless it's a .so in > certain locations. > > Should the warning be ignored in my case ? IMHO relative symlinks are asking for trouble. Quite often '../' constructs break on fs borders. qmake builds are known to suffer from this. The argument with chroots and absolute symlinks is valid as well, so one needs to weigh how often one installs in chroots and accesses the files w/o checking vs how often people install parts on different partitions, NFS storage due to bad planning or due to low space constraints. Corner case vs corner case. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bruno at postle.net Sat Aug 16 22:30:11 2008 From: bruno at postle.net (Bruno Postle) Date: Sat, 16 Aug 2008 23:30:11 +0100 Subject: [Fedora-packaging] problem with mock, builds only static library Message-ID: <20080816223011.GF3683@postle.net> I'm looking at packaging TinySVM for fedora and I have a src.rpm that builds fine with rpmbuild: http://bugbear.postle.net/~bruno/apt/fedora/linux/9/x86_64/SRPMS.panorama/TinySVM-0.09-1.fc9.src.rpm ..except that when I build in mock, all I get is a static library and no dynamic libraries. The error message is: *** Warning: This library needs some functionality provided by -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. This doesn't make sense, the root seems to have everything needed. What am I missing? -- Bruno From stephen.j.sweeney at googlemail.com Sat Aug 16 18:02:15 2008 From: stephen.j.sweeney at googlemail.com (Stephen Sweeney) Date: Sat, 16 Aug 2008 19:02:15 +0100 Subject: [Fedora-packaging] Removal of illegal packages Message-ID: Hi there, It is with much regret that I have to ask you to remove the following packages from your repositories, blobwars (Blob Wars : Metal Blob Solid) starfighter (Project: Starfighter) blobAndConquer (Blob Wars : Blob And Conquer) viruskiller (Virus Killer) It has been brought to my attention by a Happy Penguin regular, leileilol, that the packages contain resources that are non-free and, in some cases, ripped from other games and still copyrighted. They should all be removed immediately to avoid any legal issues. It would be within the interests of all if we could get these games removed ASAP so that your distributions are not affected by any legal issues. Please could you forward this email along to any one else you may know who is a package maintainer. Thank you, Stephen Sweeney -- The Battle for the Solar System http://www.battleforthesolarsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From guus at debian.org Sat Aug 16 19:46:16 2008 From: guus at debian.org (Guus Sliepen) Date: Sat, 16 Aug 2008 21:46:16 +0200 Subject: [Fedora-packaging] Re: Removal of illegal packages In-Reply-To: References: Message-ID: <20080816194616.GC15345@sliepen.org> On Sat, Aug 16, 2008 at 07:02:15PM +0100, Stephen Sweeney wrote: > It has been brought to my attention by a Happy Penguin regular, leileilol, > that the packages contain resources that are non-free and, in some cases, > ripped from other games and still copyrighted. They should all be removed > immediately to avoid any legal issues. > > It would be within the interests of all if we could get these games removed > ASAP so that your distributions are not affected by any legal issues. Thanks for notifying us! Can you send us more information regarding which files are non-free and in each case, in what way? If the non-free content consists of just for a few images or music files, the Debian way is to remove only the offending content from the upstream source. -- Met vriendelijke groet / with kind regards, Guus Sliepen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From stephen.j.sweeney at googlemail.com Sat Aug 16 19:54:24 2008 From: stephen.j.sweeney at googlemail.com (Stephen Sweeney) Date: Sat, 16 Aug 2008 20:54:24 +0100 Subject: [Fedora-packaging] Re: Removal of illegal packages In-Reply-To: <20080816194616.GC15345@sliepen.org> References: <20080816194616.GC15345@sliepen.org> Message-ID: The offending data is music, sound effects and graphics for all packages (blobwars, blobAndConquer, viruskiller and starfighter). Thanks, Steve 2008/8/16 Guus Sliepen > On Sat, Aug 16, 2008 at 07:02:15PM +0100, Stephen Sweeney wrote: > > > It has been brought to my attention by a Happy Penguin regular, > leileilol, > > that the packages contain resources that are non-free and, in some cases, > > ripped from other games and still copyrighted. They should all be removed > > immediately to avoid any legal issues. > > > > It would be within the interests of all if we could get these games > removed > > ASAP so that your distributions are not affected by any legal issues. > > Thanks for notifying us! Can you send us more information regarding which > files > are non-free and in each case, in what way? If the non-free content > consists of > just for a few images or music files, the Debian way is to remove only the > offending content from the upstream source. > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkinLogACgkQAxLow12M2ns96wCgsXilSd2mnS5RkJ15cjbyHwro > FkUAnjXsPoLtri3/5W+o1X7Fal8dEFtH > =F7HE > -----END PGP SIGNATURE----- > > -- The Battle for the Solar System http://www.battleforthesolarsystem.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdong at ubuntu.com Sun Aug 17 12:31:51 2008 From: jdong at ubuntu.com (jdong at ubuntu.com) Date: Sun, 17 Aug 2008 08:31:51 -0400 Subject: [Fedora-packaging] Re: Removal of illegal packages In-Reply-To: References: <20080816194616.GC15345@sliepen.org> Message-ID: Thanks for letting us know, Steve. Do you have links to any references that confirm these claims? Thanks, John On 8/16/08, Stephen Sweeney wrote: > The offending data is music, sound effects and graphics for all packages > (blobwars, blobAndConquer, viruskiller and starfighter). > > Thanks, > > Steve > > 2008/8/16 Guus Sliepen > >> On Sat, Aug 16, 2008 at 07:02:15PM +0100, Stephen Sweeney wrote: >> >> > It has been brought to my attention by a Happy Penguin regular, >> leileilol, >> > that the packages contain resources that are non-free and, in some >> > cases, >> > ripped from other games and still copyrighted. They should all be >> > removed >> > immediately to avoid any legal issues. >> > >> > It would be within the interests of all if we could get these games >> removed >> > ASAP so that your distributions are not affected by any legal issues. >> >> Thanks for notifying us! Can you send us more information regarding which >> files >> are non-free and in each case, in what way? If the non-free content >> consists of >> just for a few images or music files, the Debian way is to remove only the >> offending content from the upstream source. >> >> -- >> Met vriendelijke groet / with kind regards, >> Guus Sliepen >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iEYEARECAAYFAkinLogACgkQAxLow12M2ns96wCgsXilSd2mnS5RkJ15cjbyHwro >> FkUAnjXsPoLtri3/5W+o1X7Fal8dEFtH >> =F7HE >> -----END PGP SIGNATURE----- >> >> > > > -- > The Battle for the Solar System > http://www.battleforthesolarsystem.com > From kili at outback.escape.de Sun Aug 17 18:38:26 2008 From: kili at outback.escape.de (Matthias Kilian) Date: Sun, 17 Aug 2008 20:38:26 +0200 Subject: [Fedora-packaging] Re: Removal of illegal packages In-Reply-To: References: <20080816194616.GC15345@sliepen.org> Message-ID: <20080817183825.GA28684@petunia.outback.escape.de> On Sun, Aug 17, 2008 at 08:31:51AM -0400, jdong at ubuntu.com wrote: > Thanks for letting us know, Steve. Do you have links to any references > that confirm these claims? I think it's here: http://www.happypenguin.org/forums/viewtopic.php?t=4725&highlight= Ciao, Kili From petersen at redhat.com Fri Aug 22 07:53:33 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 22 Aug 2008 17:53:33 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> Message-ID: <48AE707D.60500@redhat.com> Hi Yaakov, Sorry for the slow response. I was away last week. > I've revised the guidelines once again to cover the issues brought up > when I brought them before the packaging committee. As follows is a > list of the issues I've heard, and how they are fixed. Thanks for your ongoing work on this. :) > * %buildsubdir is not a common way of doing things > ** we need this macro in the install phase to get at the working dir > we used to compile the package. This is not haskell specific and should really not be needed. Let's try to get rid of it. But how are packages supposed to get these macros? Surely each package is not going to include all of http://ynemoy.fedorapeople.org/haskell/macros.ghc ? The macros are not really that ghc specific: they should be prefixed cabal not ghc. IMHO some of it seems to be overkill. - if %ghc_autotools is necessary, can the -p option be made optional? I attach an (untested) which cleans up the macro file a bit. > * this file detection stuff is scary > ** I've put it into a series of macros and documented it Ok, that might be useful. :) > * this register stuff looks kinky > ** for starters, it's needed so the compiler knows where to look for > certain packages > ** it's been converted to a bunch of macros Less worried about that than I used to be. Again the macros don't really buy much. I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do we need them? > I also think that if we can make this any more simple, then the only > thing that cabal-rpm really really needs to do is detect if a package > is a library, binary, or both, and then fill in some of the > dependencies automatically, which it's not clever enough yet to do > properly anyways. We may just need to create a few rpm templates, and > be done with it. Yes, maybe. > Anyways, I present the guidelines once more for review. I will try to > comandeer the help of the people in the SIG to start putting together > a repo of packages using these macros. The deadline for the F10 > feature is coming up soon, and I want to have it in a relatively > stable shape, even though we have time to fine tune the details later. We really need to get some packages in the queue reviewed first to check the sanity of the draft. And IMHO better to use KISS than too much overengineering. We can add more macros if necessary after more experience at a later revision. Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: macros.haskell.patch Type: application/mbox Size: 2941 bytes Desc: not available URL: From michel.sylvan at gmail.com Sat Aug 23 18:03:23 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 23 Aug 2008 14:03:23 -0400 Subject: [Fedora-packaging] GNUstep filesystem layout discussion Message-ID: What === GNUstep is a Obj-C-based framework, similar to Mac OS X's Cocoa State of GNUstep in Fedora ================ GNUstep has long been excluded from Fedora due to its non-standard filesystem layout. Recently, however, its support for being installed under the FHS layout has improved. gnustep-make is now in Fedora. There are some problems with the current layout used by Fedora; see below. Other distributions =========== Debian and its derived distributions have the complete GNUstep stack already packaged. The file system layout they adopted seem to be a flattened FHS layout. Current problems ========== OpenStep/GNUstep/Cocoa allow for application bundles: self-contained directories that is treated by the application launcher (openapp in GNUstep) as applications. In GNUstep terminology, a "flattened" layout, such as used in Debian, makes the application bundles platform-specific. In an unflattened layout, however, such as used by default when using the GNUstep layout (as opposed to the FHS layout that we are constrained to use in Fedora), fat binaries are possible: binaries are stored under a directory specifying their platform. for instance: Hello.app \--- i386 | \--- hello \--- x86_64 \--- hello This seems more desirable, in that it will allow an unmodified 'openapp' launcher to work on multilib systems: the default application path is /usr/lib/GNUstep/Applications, regardless of whether %{_libdir} is /usr/lib or /usr/lib64. The problem, right now, is that GNUstep tools are currently installed in /usr/bin/. Which conflicts with util-linux-ng, where /usr/bin/ is an executable wrapper around 'setarch '. We would need to settle on our GNUstep layout, before the rest of GNUstep can be packaged. The main options right now seem to be: - FHS, flattened (like Debian). We would need to override GNUstep-make to install under %{_libdir} rather than %{_prefix}/lib. It will require a customized openapp to handle multilib systems - FHS, unflattened (like our current gnustep-make). Works well with multilib. We need to decide where to put GNUstep tools: Axel suggests /usr/bin/GNUstep/. Base libraries currently go in /usr/lib/, and are probably fine there. Moving them to /usr/lib/GNUstep/ might cause confusion as the higher-level frameworks are installed there. - Pure GNUstep layout. Everything goes in /usr/GNUstep Thoughts? Once we come up with a consensus I'll probably start a page on the Wiki. Anyone interested in joining a GNUstep SIG? Regards, -- Michel Salim http://hircus.jaiku.com/ From Axel.Thimm at ATrpms.net Sat Aug 23 19:12:19 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 23 Aug 2008 22:12:19 +0300 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: References: Message-ID: <20080823191219.GA9570@victor.nirvana> Hi, On Sat, Aug 23, 2008 at 02:03:23PM -0400, Michel Salim wrote: > What > === > GNUstep is a Obj-C-based framework, similar to Mac OS X's Cocoa > > State of GNUstep in Fedora > ================ > GNUstep has long been excluded from Fedora due to its non-standard > filesystem layout. Recently, however, its support for being installed > under the FHS layout has improved. gnustep-make is now in Fedora. > There are some problems with the current layout used by Fedora; see > below. > > Other distributions > =========== > Debian and its derived distributions have the complete GNUstep stack > already packaged. The file system layout they adopted seem to be a > flattened FHS layout. > > Current problems > ========== > OpenStep/GNUstep/Cocoa allow for application bundles: self-contained > directories that is treated by the application launcher (openapp in > GNUstep) as applications. In GNUstep terminology, a "flattened" > layout, such as used in Debian, makes the application bundles > platform-specific. In an unflattened layout, however, such as used by > default when using the GNUstep layout (as opposed to the FHS layout > that we are constrained to use in Fedora), fat binaries are possible: > binaries are stored under a directory specifying their platform. > > for instance: > > Hello.app > \--- i386 > | \--- hello > \--- x86_64 > \--- hello > > This seems more desirable, in that it will allow an unmodified > 'openapp' launcher to work on multilib systems: the default > application path is /usr/lib/GNUstep/Applications, regardless of > whether %{_libdir} is /usr/lib or /usr/lib64. Please note that the unflattened layout is not just for different archs, but even different compilers/libcombos. In a flattened world one can only support one combo which for example will make opengroupware conflict with other GNUstep apps. At least this is my understanding, I don't know how Debian has solved this, or even if opengroupware is part of Debian, so perhaps they haven't seen the issue, yet. > The problem, right now, is that GNUstep tools are currently installed > in /usr/bin/. Which conflicts with util-linux-ng, where > /usr/bin/ is an executable wrapper around 'setarch '. What if we simply crop off the from the path? Would that make us fully FHS compliant again? > We would need to settle on our GNUstep layout, before the rest of > GNUstep can be packaged. The main options right now seem to be: > - FHS, flattened (like Debian). We would need to override GNUstep-make > to install under %{_libdir} rather than %{_prefix}/lib. It will > require a customized openapp to handle multilib systems > > - FHS, unflattened (like our current gnustep-make). Works well with > multilib. We need to decide where to put GNUstep tools: Axel suggests > /usr/bin/GNUstep/. Actually I suggested putting them under %{_libexecdir} with symlinks/wrappers back to %{_bindir}. I don't think that a subdirectory under %{_bindir} is really in FHS/Fedora spirit. But now I think maybe we need to place them directly under %{_bindir} and let rpm deal with the different archs as it does for all other %{_bindir} mixing of subarchs with colors etc. > Base libraries currently go in /usr/lib/, and are probably > fine there. Shouldn't this at least go beneath %{_libdir} instead of /usr/lib? > Moving them to /usr/lib/GNUstep/ might cause confusion as the > higher-level frameworks are installed there. > > - Pure GNUstep layout. Everything goes in /usr/GNUstep Thanks for the writeup and if smeone is interested: Some discussion in context of a bug report happened here: https://bugzilla.redhat.com/show_bug.cgi?id=437551 I think Fedora's typical way of dealing with this is the following: o multiarch/multilib binaries are not supported, e.g. all other instances either hide non consumer binaries under %{_libdir}, or allow x86_64 to overwrite less colorful cousins like i386. o libraries need to be placed under %{_libdir}. > Thoughts? Once we come up with a consensus I'll probably start a > page on the Wiki. Anyone interested in joining a GNUstep SIG? I think it is important for many GNUstep app builders to voice in their experiences with the GNUstep build procedure and see how we can make sure the layout we will be "setting in stone" by approval by the FPC will be pleasing all. A wiki page will be great as we can even ask non Fedorians like the opengroupware people to have a look and see whether it would fit their software's need. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dominik at greysector.net Sat Aug 23 22:41:30 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 24 Aug 2008 00:41:30 +0200 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: References: Message-ID: <20080823224129.GA20661@mokona.greysector.net> On Sunday, 24 August 2008 at 00:20, Kevin Kofler wrote: > Michel Salim gmail.com> writes: > > - FHS, flattened (like Debian). We would need to override GNUstep-make > > to install under %{_libdir} rather than %{_prefix}/lib. It will > > require a customized openapp to handle multilib systems > > I consider this to be the only way to really comply with the FHS as required by > the Fedora Packaging Guidelines. > > And as Axel rightly pointed out, binaries do not belong to /usr/bin/GNUstep/: > if they're intended to be run directly, they should be directly under /usr/bin, > otherwise they should be under /usr/libexec/GNUstep. Sounds reasonable, +1. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From michel.sylvan at gmail.com Sun Aug 24 00:26:34 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 23 Aug 2008 20:26:34 -0400 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080823224129.GA20661@mokona.greysector.net> References: <20080823224129.GA20661@mokona.greysector.net> Message-ID: On Sat, Aug 23, 2008 at 6:41 PM, Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 24 August 2008 at 00:20, Kevin Kofler wrote: >> Michel Salim gmail.com> writes: >> > - FHS, flattened (like Debian). We would need to override GNUstep-make >> > to install under %{_libdir} rather than %{_prefix}/lib. It will >> > require a customized openapp to handle multilib systems >> >> I consider this to be the only way to really comply with the FHS as required by >> the Fedora Packaging Guidelines. >> >> And as Axel rightly pointed out, binaries do not belong to /usr/bin/GNUstep/: >> if they're intended to be run directly, they should be directly under /usr/bin, >> otherwise they should be under /usr/libexec/GNUstep. > > Sounds reasonable, +1. > So the consensus so far seems to be for using a flattened layout. Removing --disable-flattened from gnustep-make actually causes a much tighter adherence to the FHS, with %{_bindir} and %{_libdir} not containing any subdirectories. The one problem I foresee is that application bundles also contain data files. Putting them in %{_libdir}/GNUstep/Applications would mean that installing 32-bit and 64-bit versions of a bundle result in the data files being duplicated. This is probably acceptable, though. I've summarized the discussion on the Wiki: https://fedoraproject.org/wiki/PackagingDrafts/GNUstep Axel, what do you think? Seems like keeping the unflattened layout might be too much trouble; if we are already flattening /usr/bin and /usr/lib*, might as well stick with a flattened layout after all. -- Michel Salim http://hircus.jaiku.com/ From Axel.Thimm at ATrpms.net Sun Aug 24 07:46:13 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 10:46:13 +0300 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: References: <20080823191219.GA9570@victor.nirvana> Message-ID: <20080824074613.GC13091@victor.nirvana> On Sat, Aug 23, 2008 at 10:26:06PM +0000, Kevin Kofler wrote: > Axel Thimm ATrpms.net> writes: > > Please note that the unflattened layout is not just for different > > archs, but even different compilers/libcombos. In a flattened world > > one can only support one combo which for example will make > > opengroupware conflict with other GNUstep apps. > > Yuck! IMHO the answer there is the same as for other packages which think they > are a distro: they need to be fixed to work with the system libraries instead > (or the system libraries fixed to work with the packages, if that's where the > problem lies). I agree, but the library combo at GNUstep is a different beast, it doesn't have to do with different system libraries and gnustep-make does not ship any private libraries. The issue is whether gnustep-make will allow one and only one Objective-C runtime/ foundation library/graphical interface tuple (flattened), or allow for any sensible combination. Objective-C runtime is probably just gcc. For the graphical interface there is also more or less one choice in the Linux world. But for the foundation libraries there are several choices, most prominently gnustep-base and libFoundation in Linux space, and while most GNUstep owned apps use the in-house gnustep-base lib, some other prominent ones like opengroupware.org use libFoundation. So we do need to allow for the choice at runtime instead of build-time, e.g. allow for non-flattened installs of gnustep-make. I hope this makes the issues a bit clearer. IMHO we need to start with gnustep-make's FHS and non-flattened layout and fix it where it still needs fixing (gnustep-make FHS layout is very young and one could say that we are shaking out the bugs and when we are finished hopefully upstream will be glad to accept any patch we will have made to the FHS mode layout of gnustep-make). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dominik at greysector.net Sun Aug 24 12:50:38 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 24 Aug 2008 14:50:38 +0200 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: References: <20080823224129.GA20661@mokona.greysector.net> Message-ID: <20080824125038.GA22804@mokona.greysector.net> On Sunday, 24 August 2008 at 02:26, Michel Salim wrote: > On Sat, Aug 23, 2008 at 6:41 PM, Dominik 'Rathann' Mierzejewski > wrote: > > On Sunday, 24 August 2008 at 00:20, Kevin Kofler wrote: > >> Michel Salim gmail.com> writes: > >> > - FHS, flattened (like Debian). We would need to override GNUstep-make > >> > to install under %{_libdir} rather than %{_prefix}/lib. It will > >> > require a customized openapp to handle multilib systems > >> > >> I consider this to be the only way to really comply with the FHS as required by > >> the Fedora Packaging Guidelines. > >> > >> And as Axel rightly pointed out, binaries do not belong to /usr/bin/GNUstep/: > >> if they're intended to be run directly, they should be directly under /usr/bin, > >> otherwise they should be under /usr/libexec/GNUstep. > > > > Sounds reasonable, +1. > > > So the consensus so far seems to be for using a flattened layout. > Removing --disable-flattened from gnustep-make actually causes a much > tighter adherence to the FHS, with %{_bindir} and %{_libdir} not > containing any subdirectories. > > The one problem I foresee is that application bundles also contain > data files. Putting them in %{_libdir}/GNUstep/Applications would mean > that installing 32-bit and 64-bit versions of a bundle result in the > data files being duplicated. This is probably acceptable, though. If the data doesn't differ between 64bit and 32bit, it should be put in /usr/share and symlinked where necessary. > I've summarized the discussion on the Wiki: > https://fedoraproject.org/wiki/PackagingDrafts/GNUstep > > Axel, what do you think? Seems like keeping the unflattened layout > might be too much trouble; if we are already flattening /usr/bin and > /usr/lib*, might as well stick with a flattened layout after all. I'm not Axel, but I second this. ;) Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Sun Aug 24 13:16:04 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 16:16:04 +0300 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080824125038.GA22804@mokona.greysector.net> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> Message-ID: <20080824131604.GB23503@victor.nirvana> On Sun, Aug 24, 2008 at 02:50:38PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Axel, what do you think? Seems like keeping the unflattened layout > > might be too much trouble; if we are already flattening /usr/bin and > > /usr/lib*, might as well stick with a flattened layout after all. > > I'm not Axel, but I second this. ;) But please understand that we would then have chosen between libfoundation and gnustep-base, e.g. only one would be allowed in Fedora world. And thus only one subset of application packages would survive. unflattened != multiarch unflattened == choose libcombo at runtime flattened == choose libcombo at buildtime -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dominik at greysector.net Sun Aug 24 13:24:44 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 24 Aug 2008 15:24:44 +0200 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080824131604.GB23503@victor.nirvana> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> Message-ID: <20080824132444.GA23430@mokona.greysector.net> On Sunday, 24 August 2008 at 15:16, Axel Thimm wrote: > On Sun, Aug 24, 2008 at 02:50:38PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > Axel, what do you think? Seems like keeping the unflattened layout > > > might be too much trouble; if we are already flattening /usr/bin and > > > /usr/lib*, might as well stick with a flattened layout after all. > > > > I'm not Axel, but I second this. ;) > > But please understand that we would then have chosen between > libfoundation and gnustep-base, e.g. only one would be allowed in > Fedora world. And thus only one subset of application packages would > survive. > > unflattened != multiarch > unflattened == choose libcombo at runtime > flattened == choose libcombo at buildtime Hm. We don't support mixing lesstif and openmotif either. Is libfoundation incompatible with gnustep-base? Anyway, here's an idea: Put binaries in unflattened %{_libdir}/GNUstep/* and symlink to /usr/bin. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Sun Aug 24 14:17:27 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 24 Aug 2008 17:17:27 +0300 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080824132444.GA23430@mokona.greysector.net> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> Message-ID: <20080824141727.GD23503@victor.nirvana> On Sun, Aug 24, 2008 at 03:24:44PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 24 August 2008 at 15:16, Axel Thimm wrote: > > On Sun, Aug 24, 2008 at 02:50:38PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > Axel, what do you think? Seems like keeping the unflattened layout > > > > might be too much trouble; if we are already flattening /usr/bin and > > > > /usr/lib*, might as well stick with a flattened layout after all. > > > > > > I'm not Axel, but I second this. ;) > > > > But please understand that we would then have chosen between > > libfoundation and gnustep-base, e.g. only one would be allowed in > > Fedora world. And thus only one subset of application packages would > > survive. > > > > unflattened != multiarch > > unflattened == choose libcombo at runtime > > flattened == choose libcombo at buildtime > > Hm. We don't support mixing lesstif and openmotif either. Is libfoundation > incompatible with gnustep-base? While not an expert on gnustep, I think the differences are not just different implementations of the same API/ABI, I believe the libs are supposed to have different APIs. Many applications (all?) require specific libcombos to be built against. > Anyway, here's an idea: > Put binaries in unflattened %{_libdir}/GNUstep/* and symlink to /usr/bin. Binaries are probably not an issue, IMHO there are just some bugs in gnustep's implementation of the FHS (like /usr/bin/x86_64 subdirs, which we must truncate back). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rdieter at math.unl.edu Sun Aug 24 15:24:52 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 24 Aug 2008 10:24:52 -0500 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080824132444.GA23430@mokona.greysector.net> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> Message-ID: <48B17D44.1070601@math.unl.edu> Dominik 'Rathann' Mierzejewski wrote: > Hm. We don't support mixing lesstif and openmotif either. Offtopic, fwiw, we *could*, it's only because openmotif isn't in fedora. -- Rex From michel.sylvan at gmail.com Sun Aug 24 21:39:37 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 24 Aug 2008 17:39:37 -0400 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080824141727.GD23503@victor.nirvana> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> <20080824141727.GD23503@victor.nirvana> Message-ID: On Sun, Aug 24, 2008 at 10:17 AM, Axel Thimm wrote: >> > unflattened != multiarch >> > unflattened == choose libcombo at runtime >> > flattened == choose libcombo at buildtime >> >> Hm. We don't support mixing lesstif and openmotif either. Is libfoundation >> incompatible with gnustep-base? > > While not an expert on gnustep, I think the differences are not just > different implementations of the same API/ABI, I believe the libs are > supposed to have different APIs. Many applications (all?) require > specific libcombos to be built against. > >> Anyway, here's an idea: >> Put binaries in unflattened %{_libdir}/GNUstep/* and symlink to /usr/bin. > > Binaries are probably not an issue, IMHO there are just some bugs in > gnustep's implementation of the FHS (like /usr/bin/x86_64 subdirs, > which we must truncate back). So: - binaries can be flattened - library structure can be simplified: currently: %{_prefix}/lib//linux-gnu/gnu-gnu-gnu proposed: %{_libdir}/linux-gnu/gnu-gnu-gnu (remove as we'll only ever deal with 32-bit/64-bit parallel installs, and %{_libdir} handles this) or perhaps even %{_libdir}/GNUstep/gnu-gnu-gnu? If someone could point to a libFoundation set-up, we can see which of linux-gnu and gnu-gnu-gnu can be done away with. -- Michel Salim http://hircus.jaiku.com/ From Axel.Thimm at ATrpms.net Mon Aug 25 07:30:34 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 25 Aug 2008 10:30:34 +0300 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> <20080824141727.GD23503@victor.nirvana> Message-ID: <20080825073034.GA1665@victor.nirvana> On Sun, Aug 24, 2008 at 05:39:37PM -0400, Michel Salim wrote: > On Sun, Aug 24, 2008 at 10:17 AM, Axel Thimm wrote: > > >> > unflattened != multiarch > >> > unflattened == choose libcombo at runtime > >> > flattened == choose libcombo at buildtime > >> > >> Hm. We don't support mixing lesstif and openmotif either. Is libfoundation > >> incompatible with gnustep-base? > > > > While not an expert on gnustep, I think the differences are not just > > different implementations of the same API/ABI, I believe the libs are > > supposed to have different APIs. Many applications (all?) require > > specific libcombos to be built against. > > > >> Anyway, here's an idea: > >> Put binaries in unflattened %{_libdir}/GNUstep/* and symlink to /usr/bin. > > > > Binaries are probably not an issue, IMHO there are just some bugs in > > gnustep's implementation of the FHS (like /usr/bin/x86_64 subdirs, > > which we must truncate back). > > So: > - binaries can be flattened > - library structure can be simplified: > currently: %{_prefix}/lib//linux-gnu/gnu-gnu-gnu > proposed: %{_libdir}/linux-gnu/gnu-gnu-gnu > (remove as we'll only ever deal with 32-bit/64-bit parallel > installs, and %{_libdir} handles this) > > or perhaps even %{_libdir}/GNUstep/gnu-gnu-gnu? > > If someone could point to a libFoundation set-up, we can see which of > linux-gnu and gnu-gnu-gnu can be done away with. Just replace gnu-gnu-gnu with gnu-fd-gnu or gnu-fd-nil. The layout is given by gnustep-make for all consumers independent of the combo. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dominik at greysector.net Mon Aug 25 15:40:39 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 25 Aug 2008 17:40:39 +0200 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <48B17D44.1070601@math.unl.edu> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> <48B17D44.1070601@math.unl.edu> Message-ID: <20080825154039.GA32183@mokona.greysector.net> On Sunday, 24 August 2008 at 17:24, Rex Dieter wrote: > Dominik 'Rathann' Mierzejewski wrote: > > >Hm. We don't support mixing lesstif and openmotif either. > > Offtopic, fwiw, we *could*, it's only because openmotif isn't in fedora. Are you sure? AFAIK they are ABI-incompatible. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rdieter at math.unl.edu Mon Aug 25 15:53:08 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 25 Aug 2008 10:53:08 -0500 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080825154039.GA32183@mokona.greysector.net> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> <48B17D44.1070601@math.unl.edu> <20080825154039.GA32183@mokona.greysector.net> Message-ID: <48B2D564.7010701@math.unl.edu> Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 24 August 2008 at 17:24, Rex Dieter wrote: >> Dominik 'Rathann' Mierzejewski wrote: >> >>> Hm. We don't support mixing lesstif and openmotif either. >> Offtopic, fwiw, we *could*, it's only because openmotif isn't in fedora. > > Are you sure? AFAIK they are ABI-incompatible. OK, depends on your definition of mixing. I thought you meant parallel-installable. And yes, they are afaik, ABI-incompatible with different sonames. -- Rex From dominik at greysector.net Mon Aug 25 16:47:43 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 25 Aug 2008 18:47:43 +0200 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <48B2D564.7010701@math.unl.edu> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> <48B17D44.1070601@math.unl.edu> <20080825154039.GA32183@mokona.greysector.net> <48B2D564.7010701@math.unl.edu> Message-ID: <20080825164742.GB32183@mokona.greysector.net> On Monday, 25 August 2008 at 17:53, Rex Dieter wrote: > Dominik 'Rathann' Mierzejewski wrote: > >On Sunday, 24 August 2008 at 17:24, Rex Dieter wrote: > >>Dominik 'Rathann' Mierzejewski wrote: > >> > >>>Hm. We don't support mixing lesstif and openmotif either. > >>Offtopic, fwiw, we *could*, it's only because openmotif isn't in fedora. > > > >Are you sure? AFAIK they are ABI-incompatible. > > OK, depends on your definition of mixing. I thought you meant > parallel-installable. And yes, they are afaik, ABI-incompatible with > different sonames. Hm, I was under the impression that they had the same sonames, but I may have been wrong. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pertusus at free.fr Mon Aug 25 16:59:37 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 25 Aug 2008 18:59:37 +0200 Subject: [Fedora-packaging] Re: GNUstep filesystem layout discussion In-Reply-To: <20080825164742.GB32183@mokona.greysector.net> References: <20080823224129.GA20661@mokona.greysector.net> <20080824125038.GA22804@mokona.greysector.net> <20080824131604.GB23503@victor.nirvana> <20080824132444.GA23430@mokona.greysector.net> <48B17D44.1070601@math.unl.edu> <20080825154039.GA32183@mokona.greysector.net> <48B2D564.7010701@math.unl.edu> <20080825164742.GB32183@mokona.greysector.net> Message-ID: <20080825165937.GB7722@free.fr> On Mon, Aug 25, 2008 at 06:47:43PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Hm, I was under the impression that they had the same sonames, but > I may have been wrong. The openmotif and lesstif soname have the same base name but different numbers. lesstif is like libXm.so.2 and openmotif libXm.so.3. This is asking for future trouble, though appplications can have Requires: lesstif when they have been built with lesstif to mitigate the issue. I am not exaclty sure what would be the right way in that case, though, so I have postponed looking more at that issue. -- Pat From mszpak at wp.pl Mon Aug 25 21:06:58 2008 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Mon, 25 Aug 2008 23:06:58 +0200 Subject: [Fedora-packaging] Game data packaging Message-ID: Hi, I'm currently preparing package for one small game. It uses standard automake. Game assumes that its data will be in $datadir/games/gamename and there is no easy way to change it (except patching configure.in). I checked my system and there is only one game (gbrainy) with data in /usr/share/games(/gbrainy). I would like to ask is there any advise to put game data in games subdir or it should be treated as a normal application? Regards Marcin From j.w.r.degoede at hhs.nl Mon Aug 25 21:19:29 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 25 Aug 2008 23:19:29 +0200 Subject: [Fedora-packaging] Game data packaging In-Reply-To: References: Message-ID: <48B321E1.5@hhs.nl> Marcin Zaj?czkowski wrote: > Hi, > > > I'm currently preparing package for one small game. It uses standard > automake. Game assumes that its data will be in $datadir/games/gamename > and there is no easy way to change it (except patching configure.in). I > checked my system and there is only one game (gbrainy) with data in > /usr/share/games(/gbrainy). > I would like to ask is there any advise to put game data in games subdir > or it should be treated as a normal application? > It should be treated as a normal application, so please patch configure Regards, Hans From mr.ecik at gmail.com Mon Aug 25 21:09:30 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Mon, 25 Aug 2008 23:09:30 +0200 Subject: [Fedora-packaging] Game data packaging In-Reply-To: References: Message-ID: <668bb39a0808251409j2c83a55fke57759158ca5c9b8@mail.gmail.com> http://fedoraproject.org/wiki/SIGs/Games/Packaging ? "Data files (maps, pixmaps, sounds) go in %{_datadir}/%{name} , not %{_datadir}/games/%{name} . Binaries go in %{_bindir} and not /usr/games. According to the FHS, the use of /usr/share/games and /usr/games is optional, and we recommend not using either for consistency, so that games are packaged like all other applications. " 2008/8/25 Marcin Zaj?czkowski : > Hi, > > > I'm currently preparing package for one small game. It uses standard > automake. Game assumes that its data will be in $datadir/games/gamename > and there is no easy way to change it (except patching configure.in). I > checked my system and there is only one game (gbrainy) with data in > /usr/share/games(/gbrainy). > I would like to ask is there any advise to put game data in games subdir > or it should be treated as a normal application? > > > Regards > Marcin > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- Micha? Bentkowski mr.ecik at gmail.com From mszpak at wp.pl Mon Aug 25 21:26:20 2008 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Mon, 25 Aug 2008 23:26:20 +0200 Subject: [Fedora-packaging] Re: Game data packaging In-Reply-To: <48B321E1.5@hhs.nl> References: <48B321E1.5@hhs.nl> Message-ID: On 2008-08-25 23:19, Hans de Goede wrote: > Marcin Zaj?czkowski wrote: (...) >> I'm currently preparing package for one small game. It uses standard >> automake. Game assumes that its data will be in $datadir/games/gamename >> and there is no easy way to change it (except patching configure.in). I >> checked my system and there is only one game (gbrainy) with data in >> /usr/share/games(/gbrainy). >> I would like to ask is there any advise to put game data in games subdir >> or it should be treated as a normal application? > > It should be treated as a normal application, so please patch configure Thanks guys for the quick answers. I missed a link to SIG pages from Package Maintainers page. Best Marcin From michel.sylvan at gmail.com Tue Aug 26 05:09:46 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 26 Aug 2008 01:09:46 -0400 Subject: [Fedora-packaging] Macro expansion problem Message-ID: At the risk of asking the obvious, why does this fail: %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core | cut -d "=" -f 2 | cut - d "," -f 1) Requires: mono(nunit.core) = %{nunitver} but this succeeds: %define nunitver 2.2.10.0 Requires: mono(nunit.core) = %{nunitver} context: this is for monodevelop, that comes from upstream with bundled nunit DLLs. I've patched it to use the system-provided nunit DLLs, but find-mono.req.sh does not pick up the correct dependencies, thus the manual patch. Thanks, -- Michel Salim http://hircus.jaiku.com/ From tgl at redhat.com Tue Aug 26 05:34:09 2008 From: tgl at redhat.com (Tom Lane) Date: Tue, 26 Aug 2008 01:34:09 -0400 Subject: [Fedora-packaging] Macro expansion problem In-Reply-To: References: Message-ID: <20322.1219728849@sss.pgh.pa.us> "Michel Salim" writes: > At the risk of asking the obvious, why does this fail: > %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core > | cut -d "=" -f 2 | cut -d "," -f 1) > Requires: mono(nunit.core) = %{nunitver} I'm hardly an expert, but it seems like this is assuming that gacutil will be installed in *any* context where the specfile is examined, in particular before any of the specfile's Requires: or BuildRequires: could be enforced. (Likewise for tail, grep, and cut, but those at least have some small prayer of being there in the environment of non-core packages.) You can get away with this kind of thing in some cases where the macro's value doesn't really matter before the package is built and/or installed (I have some packages that do similar things and seem to work). But I'm thinking a Requires: cannot qualify for that, since it's likely to be evaluated long before either the package or its dependencies have been installed. regards, tom lane From Axel.Thimm at ATrpms.net Tue Aug 26 09:31:46 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Aug 2008 12:31:46 +0300 Subject: [Fedora-packaging] Re: Macro expansion problem In-Reply-To: References: Message-ID: <20080826093146.GC26699@victor.nirvana> On Tue, Aug 26, 2008 at 01:09:46AM -0400, Michel Salim wrote: > At the risk of asking the obvious, why does this fail: You didn't write *how* it fails. > %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core > | cut -d "=" -f 2 | cut - > d "," -f 1) > > Requires: mono(nunit.core) = %{nunitver} > > but this succeeds: > > %define nunitver 2.2.10.0 > Requires: mono(nunit.core) = %{nunitver} > > context: this is for monodevelop, that comes from upstream with > bundled nunit DLLs. I've patched it to use the system-provided nunit > DLLs, but find-mono.req.sh does not pick up the correct dependencies, > thus the manual patch. > > Thanks, > Try echo "%{nunitver}"; exit in %prep and play with different settings of nunitver to debug this. As Tom wrote, you need to have BuildRequired anything that is executed and the src.rpm build will be issuing warning (which you can ignore) if the BRs happen to not be installed. BTW this is not really a fedora-packaging question, but rather fedora-devel I think (it is not guideline related). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Aug 26 11:46:50 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Aug 2008 06:46:50 -0500 Subject: [Fedora-packaging] Macro expansion problem In-Reply-To: References: Message-ID: <48B3ED2A.4090702@math.unl.edu> Michel Salim wrote: > At the risk of asking the obvious, why does this fail: > > %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core > | cut -d "=" -f 2 | cut - > d "," -f 1) > > Requires: mono(nunit.core) = %{nunitver} I'll venture because our buildsys needs to (re)generate the srpm, and at that time, no BR's are installed and gacutil isn't available => failure. To protect against that, do something like: %define nunitver %(gacutil -l nunit.core 2>& /dev/null | ...) %if "x%{?nunitver}" != "x" Requires: mono(nunit.core) = %{nunitver} %endif -- Rex From michel.sylvan at gmail.com Tue Aug 26 17:39:00 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 26 Aug 2008 13:39:00 -0400 Subject: [Fedora-packaging] Macro expansion problem In-Reply-To: <48B3ED2A.4090702@math.unl.edu> References: <48B3ED2A.4090702@math.unl.edu> Message-ID: On Tue, Aug 26, 2008 at 7:46 AM, Rex Dieter wrote: > Michel Salim wrote: >> >> At the risk of asking the obvious, why does this fail: >> >> %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core >> | cut -d "=" -f 2 | cut - >> d "," -f 1) >> >> Requires: mono(nunit.core) = %{nunitver} > > I'll venture because our buildsys needs to (re)generate the srpm, and at > that time, no BR's are installed and gacutil isn't available => failure. > To protect against that, do something like: > > %define nunitver %(gacutil -l nunit.core 2>& /dev/null | ...) > > %if "x%{?nunitver}" != "x" > Requires: mono(nunit.core) = %{nunitver} > %endif > Axel: It fails by being empty. Tom, Rex: as Rex said, it is because BRs are not installed when the SRPM is regenerated (perhaps we need a different directive, like PreBuildRequires: ? Hmm) So in this case, nunitver will *always* be empty, so I'm not sure how the test will help. Manually coding in the value will work; now whenever nunit ABI changes, instead of just bumping up release number and rebuilding, I'll have to also update the requirement. Doable. Thanks, -- Michel Salim http://hircus.jaiku.com/ From Axel.Thimm at ATrpms.net Tue Aug 26 17:47:42 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 26 Aug 2008 20:47:42 +0300 Subject: [Fedora-packaging] Re: Macro expansion problem In-Reply-To: References: <48B3ED2A.4090702@math.unl.edu> Message-ID: <20080826174742.GE10210@victor.nirvana> On Tue, Aug 26, 2008 at 01:39:00PM -0400, Michel Salim wrote: > On Tue, Aug 26, 2008 at 7:46 AM, Rex Dieter wrote: > > Michel Salim wrote: > >> > >> At the risk of asking the obvious, why does this fail: > >> > >> %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core > >> | cut -d "=" -f 2 | cut - > >> d "," -f 1) > >> > >> Requires: mono(nunit.core) = %{nunitver} > > > > I'll venture because our buildsys needs to (re)generate the srpm, and at > > that time, no BR's are installed and gacutil isn't available => failure. > > To protect against that, do something like: > > > > %define nunitver %(gacutil -l nunit.core 2>& /dev/null | ...) > > > > %if "x%{?nunitver}" != "x" > > Requires: mono(nunit.core) = %{nunitver} > > %endif > > > Axel: It fails by being empty. > > Tom, Rex: as Rex said, it is because BRs are not installed when the > SRPM is regenerated (perhaps we need a different directive, like > PreBuildRequires: ? Hmm) > > So in this case, nunitver will *always* be empty, so I'm not sure how > the test will help. This idiom is often used with perl/python/php etc. The first phase creating the src.rpm will be giving you some warnings, but the second phase, the actual building of the binaries will have the bits in place due to the BuildRequires, so it will not be empty then. > Manually coding in the value will work; now whenever nunit ABI > changes, instead of just bumping up release number and rebuilding, > I'll have to also update the requirement. Doable. > > Thanks, > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jwilson at redhat.com Tue Aug 26 18:35:51 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 26 Aug 2008 14:35:51 -0400 Subject: [Fedora-packaging] Re: Macro expansion problem In-Reply-To: <20080826174742.GE10210@victor.nirvana> References: <20080826174742.GE10210@victor.nirvana> Message-ID: <200808261435.52036.jwilson@redhat.com> On Tuesday 26 August 2008 13:47:42 Axel Thimm wrote: > On Tue, Aug 26, 2008 at 01:39:00PM -0400, Michel Salim wrote: > > On Tue, Aug 26, 2008 at 7:46 AM, Rex Dieter wrote: > > > Michel Salim wrote: > > >> At the risk of asking the obvious, why does this fail: > > >> > > >> %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core > > >> > > >> | cut -d "=" -f 2 | cut - > > >> > > >> d "," -f 1) > > >> > > >> Requires: mono(nunit.core) = %{nunitver} > > > > > > I'll venture because our buildsys needs to (re)generate the srpm, and > > > at that time, no BR's are installed and gacutil isn't available => > > > failure. To protect against that, do something like: > > > > > > %define nunitver %(gacutil -l nunit.core 2>& /dev/null | ...) > > > > > > %if "x%{?nunitver}" != "x" > > > Requires: mono(nunit.core) = %{nunitver} > > > %endif > > > > Axel: It fails by being empty. > > > > Tom, Rex: as Rex said, it is because BRs are not installed when the > > SRPM is regenerated (perhaps we need a different directive, like > > PreBuildRequires: ? Hmm) > > > > So in this case, nunitver will *always* be empty, so I'm not sure how > > the test will help. > > This idiom is often used with perl/python/php etc. The first phase > creating the src.rpm will be giving you some warnings, but the second > phase, the actual building of the binaries will have the bits in place > due to the BuildRequires, so it will not be empty then. Indeed. Scope out this snippet from rrdtool: # eval to 2.3 if python isn't yet present, workaround for no python in fc4 minimal buildroot %{!?python_version: %define python_version %(%{__python} -c 'import sys; print sys.version.split(" ")[0]' || echo "2.3")} As the comment suggests, python wasn't part of the minimal buildroot in fc4, so during the re-creating the srpm stage, the '|| echo "2.3"' part of the macro set a BR on python >= 2.3 initially when python wasn't yet there, then when the actual build started after mock had installed all the BR, it evaluated to the proper version for the dist. Same sort of thing should work for you. Note to self: that can probably be dropped from rrdtool now, since fc4 ain't exactly supported anymore... -- Jarod Wilson jarod at redhat.com From tibbs at math.uh.edu Tue Aug 26 18:36:27 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 26 Aug 2008 13:36:27 -0500 Subject: [Fedora-packaging] Macro expansion problem In-Reply-To: References: <48B3ED2A.4090702@math.unl.edu> Message-ID: >>>>> "MS" == Michel Salim writes: MS> So in this case, nunitver will *always* be empty, so I'm not sure MS> how the test will help. You just need to make sure that it's never empty. If the expansion fails, you set it to '0' or "NotInstalled" or whatever. All you have to make sure is that the specfile still parses when the package isn't installed. - J< From michel.sylvan at gmail.com Tue Aug 26 21:33:13 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 26 Aug 2008 17:33:13 -0400 Subject: [Fedora-packaging] Re: Macro expansion problem In-Reply-To: <20080826174742.GE10210@victor.nirvana> References: <48B3ED2A.4090702@math.unl.edu> <20080826174742.GE10210@victor.nirvana> Message-ID: On Tue, Aug 26, 2008 at 1:47 PM, Axel Thimm wrote: > On Tue, Aug 26, 2008 at 01:39:00PM -0400, Michel Salim wrote: >> On Tue, Aug 26, 2008 at 7:46 AM, Rex Dieter wrote: >> > Michel Salim wrote: >> >> >> >> At the risk of asking the obvious, why does this fail: >> >> >> >> %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core >> >> | cut -d "=" -f 2 | cut - >> >> d "," -f 1) >> >> >> >> Requires: mono(nunit.core) = %{nunitver} >> > >> > I'll venture because our buildsys needs to (re)generate the srpm, and at >> > that time, no BR's are installed and gacutil isn't available => failure. >> > To protect against that, do something like: >> > >> > %define nunitver %(gacutil -l nunit.core 2>& /dev/null | ...) >> > >> > %if "x%{?nunitver}" != "x" >> > Requires: mono(nunit.core) = %{nunitver} >> > %endif >> > >> Axel: It fails by being empty. >> >> Tom, Rex: as Rex said, it is because BRs are not installed when the >> SRPM is regenerated (perhaps we need a different directive, like >> PreBuildRequires: ? Hmm) >> >> So in this case, nunitver will *always* be empty, so I'm not sure how >> the test will help. > > This idiom is often used with perl/python/php etc. The first phase > creating the src.rpm will be giving you some warnings, but the second > phase, the actual building of the binaries will have the bits in place > due to the BuildRequires, so it will not be empty then. Aha! Yes, cute. The Requires: that end up in the binary package will actually be the proper values, then, not the values that end up in the source RPM? -- Michel Salim http://hircus.jaiku.com/ From michel.sylvan at gmail.com Tue Aug 26 21:37:02 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 26 Aug 2008 17:37:02 -0400 Subject: [Fedora-packaging] Re: Game data packaging In-Reply-To: References: <48B321E1.5@hhs.nl> Message-ID: 2008/8/25 Marcin Zaj?czkowski : > On 2008-08-25 23:19, Hans de Goede wrote: >> Marcin Zaj?czkowski wrote: > (...) >>> I'm currently preparing package for one small game. It uses standard >>> automake. Game assumes that its data will be in $datadir/games/gamename >>> and there is no easy way to change it (except patching configure.in). I >>> checked my system and there is only one game (gbrainy) with data in >>> /usr/share/games(/gbrainy). >>> I would like to ask is there any advise to put game data in games subdir >>> or it should be treated as a normal application? >> >> It should be treated as a normal application, so please patch configure > > Thanks guys for the quick answers. > > I missed a link to SIG pages from Package Maintainers page. > While you're at it, could you file a bug against gbrainy? Thanks, -- Michel Salim http://hircus.jaiku.com/ From Axel.Thimm at ATrpms.net Tue Aug 26 21:49:34 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 27 Aug 2008 00:49:34 +0300 Subject: [Fedora-packaging] Re: Macro expansion problem In-Reply-To: References: <48B3ED2A.4090702@math.unl.edu> <20080826174742.GE10210@victor.nirvana> Message-ID: <20080826214934.GA21470@victor.nirvana> On Tue, Aug 26, 2008 at 05:33:13PM -0400, Michel Salim wrote: > On Tue, Aug 26, 2008 at 1:47 PM, Axel Thimm wrote: > > On Tue, Aug 26, 2008 at 01:39:00PM -0400, Michel Salim wrote: > >> On Tue, Aug 26, 2008 at 7:46 AM, Rex Dieter wrote: > >> > Michel Salim wrote: > >> >> > >> >> At the risk of asking the obvious, why does this fail: > >> >> > >> >> %define nunitver %(gacutil -l nunit.core | tail -n 2 | grep nunit.core > >> >> | cut -d "=" -f 2 | cut - > >> >> d "," -f 1) > >> >> > >> >> Requires: mono(nunit.core) = %{nunitver} > >> > > >> > I'll venture because our buildsys needs to (re)generate the srpm, and at > >> > that time, no BR's are installed and gacutil isn't available => failure. > >> > To protect against that, do something like: > >> > > >> > %define nunitver %(gacutil -l nunit.core 2>& /dev/null | ...) > >> > > >> > %if "x%{?nunitver}" != "x" > >> > Requires: mono(nunit.core) = %{nunitver} > >> > %endif > >> > > >> Axel: It fails by being empty. > >> > >> Tom, Rex: as Rex said, it is because BRs are not installed when the > >> SRPM is regenerated (perhaps we need a different directive, like > >> PreBuildRequires: ? Hmm) > >> > >> So in this case, nunitver will *always* be empty, so I'm not sure how > >> the test will help. > > > > This idiom is often used with perl/python/php etc. The first phase > > creating the src.rpm will be giving you some warnings, but the second > > phase, the actual building of the binaries will have the bits in place > > due to the BuildRequires, so it will not be empty then. > > Aha! Yes, cute. The Requires: that end up in the binary package will > actually be the proper values, then, not the values that end up in the > source RPM? Yes, the values at the binary build, not at the src.rpm build. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From debarshi.ray at gmail.com Wed Aug 27 04:43:47 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 27 Aug 2008 10:13:47 +0530 Subject: [Fedora-packaging] Include ia64 tracker bug in review guidelines Message-ID: <3170f42f0808262143p5f939652l59acf5a6a9844e91@mail.gmail.com> The package review guidelines [1] do not mention the tracker bug for ia64 [2] to track 'ExcludeArch: ia64' packages. Should it not be updated? Happy hacking, Debarshi [1] https://fedoraproject.org/wiki/Packaging/ReviewGuidelines [2] https://bugzilla.redhat.com/show_bug.cgi?id=FE-ExcludeArch-ia64 From michel.sylvan at gmail.com Wed Aug 27 05:11:07 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 27 Aug 2008 01:11:07 -0400 Subject: [Fedora-packaging] Include ia64 tracker bug in review guidelines In-Reply-To: <3170f42f0808262143p5f939652l59acf5a6a9844e91@mail.gmail.com> References: <3170f42f0808262143p5f939652l59acf5a6a9844e91@mail.gmail.com> Message-ID: On Wed, Aug 27, 2008 at 12:43 AM, Debarshi Ray wrote: > The package review guidelines [1] do not mention the tracker bug for > ia64 [2] to track 'ExcludeArch: ia64' packages. Should it not be > updated? > Isn't ia64 a secondary arch? It can be hard for the packager and reviewer to notice an ia64 build failure since Koji does not provide an ia64 build. -- Michel Salim http://hircus.jaiku.com/ From paul at city-fan.org Wed Aug 27 08:02:43 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 27 Aug 2008 09:02:43 +0100 Subject: [Fedora-packaging] Include ia64 tracker bug in review guidelines In-Reply-To: References: <3170f42f0808262143p5f939652l59acf5a6a9844e91@mail.gmail.com> Message-ID: <48B50A23.9070202@city-fan.org> Michel Salim wrote: > On Wed, Aug 27, 2008 at 12:43 AM, Debarshi Ray wrote: >> The package review guidelines [1] do not mention the tracker bug for >> ia64 [2] to track 'ExcludeArch: ia64' packages. Should it not be >> updated? Yes, and the same for the sparc architectures IMHO. (http://bugzilla.redhat.com/251073) > Isn't ia64 a secondary arch? It can be hard for the packager and > reviewer to notice an ia64 build failure since Koji does not provide > an ia64 build. Well if a packager hasn't had cause to try a secondary arch build, they won't have found the need to add an ExcludeArch for that arch either. If they've added one for whatever reason, it needs to be tracked the same as any other arch. The fedora-packager-setup script now includes koji configs for doing secondary arch builds for those that are interested. The secondary arch maintainers do rebuilds of most packages to create the secondary arch releases, and the regular package maintainers get task completion emails from koji that may alert them to issues with their packages that they wouldn't have found themselves. So I say yes, the trackers for secondary arches need to be referenced the same as the primary arches. Paul. From bruno at postle.net Wed Aug 27 18:00:35 2008 From: bruno at postle.net (Bruno Postle) Date: Wed, 27 Aug 2008 19:00:35 +0100 Subject: [Fedora-packaging] problem with mock, builds only static library In-Reply-To: <20080816223011.GF3683@postle.net> References: <20080816223011.GF3683@postle.net> Message-ID: <20080827180035.GO3683@postle.net> On Sat 16-Aug-2008 at 23:30 +0100, Bruno Postle wrote: > I'm looking at packaging TinySVM for fedora and I have a src.rpm that > builds fine with rpmbuild: > > http://bugbear.postle.net/~bruno/apt/fedora/linux/9/x86_64/SRPMS.panorama/TinySVM-0.09-1.fc9.src.rpm I still have this problem, I forgot to link to the .spec file before: http://bugbear.postle.net/~bruno/apt/SPECS/TinySVM.spec > ..except that when I build in mock, all I get is a static library and no > dynamic libraries. The error message is: > > *** Warning: This library needs some functionality provided by -lm. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > *** Since this library must not contain undefined symbols, > *** because either the platform does not support them or > *** it was explicitly requested with -no-undefined, > *** libtool will only create a static version of it. > > This doesn't make sense, the root seems to have everything needed. What > am I missing? From mszpak at wp.pl Wed Aug 27 18:18:55 2008 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Wed, 27 Aug 2008 20:18:55 +0200 Subject: [Fedora-packaging] Re: Game data packaging In-Reply-To: References: <48B321E1.5@hhs.nl> Message-ID: On 2008-08-26 23:37, Michel Salim wrote: > 2008/8/25 Marcin Zaj?czkowski : >> On 2008-08-25 23:19, Hans de Goede wrote: >>> Marcin Zaj?czkowski wrote: >> (...) >>>> I'm currently preparing package for one small game. It uses standard >>>> automake. Game assumes that its data will be in $datadir/games/gamename >>>> and there is no easy way to change it (except patching configure.in). I >>>> checked my system and there is only one game (gbrainy) with data in >>>> /usr/share/games(/gbrainy). >>>> I would like to ask is there any advise to put game data in games subdir >>>> or it should be treated as a normal application? >>> It should be treated as a normal application, so please patch configure >> Thanks guys for the quick answers. >> >> I missed a link to SIG pages from Package Maintainers page. >> > While you're at it, could you file a bug against gbrainy? Sure. https://bugzilla.redhat.com/show_bug.cgi?id=460353 Regards Marcin From denis at poolshark.org Wed Aug 27 18:29:21 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 27 Aug 2008 20:29:21 +0200 Subject: [Fedora-packaging] problem with mock, builds only static library In-Reply-To: <20080827180035.GO3683@postle.net> References: <20080816223011.GF3683@postle.net> <20080827180035.GO3683@postle.net> Message-ID: <48B59D01.5010303@poolshark.org> Bruno Postle wrote: > On Sat 16-Aug-2008 at 23:30 +0100, Bruno Postle wrote: >> I'm looking at packaging TinySVM for fedora and I have a src.rpm that >> builds fine with rpmbuild: >> >> http://bugbear.postle.net/~bruno/apt/fedora/linux/9/x86_64/SRPMS.panorama/TinySVM-0.09-1.fc9.src.rpm >> > > I still have this problem, I forgot to link to the .spec file before: > > http://bugbear.postle.net/~bruno/apt/SPECS/TinySVM.spec The "-rpath /usr/lib64" on the libtool link line is the problem. Also, it's compiling with '-O9 -funroll-all-loops', which is scary. From loupgaroublond at gmail.com Wed Aug 27 22:47:05 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 27 Aug 2008 18:47:05 -0400 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48AE707D.60500@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> Message-ID: <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> On Fri, Aug 22, 2008 at 3:53 AM, Jens Petersen wrote: > Hi Yaakov, > > Sorry for the slow response. I was away last week. Ditto. >> * %buildsubdir is not a common way of doing things >> ** we need this macro in the install phase to get at the working dir >> we used to compile the package. > > This is not haskell specific and should really not be needed. > Let's try to get rid of it. It's needed for the macros that do file detection later on. Once we cd into the buildroot, we need a way of accessing the old dir we used to compile the package. Therefore, I've put it in a macro, and both sets of macros are mandatory. If you have a better solution, please fix it. > But how are packages supposed to get these macros? > Surely each package is not going to include all of > http://ynemoy.fedorapeople.org/haskell/macros.ghc ? That file is going to be packaged with ghc itself. I've submitted the following bug. https://bugzilla.redhat.com/show_bug.cgi?id=460304 > The macros are not really that ghc specific: they should be prefixed cabal > not ghc. Technically no, but I want to differentiate between what the theoretical command might be for foo haskell compiler, and what nuances there might be between compilers. > > IMHO some of it seems to be overkill. How so? For the most part, i'm converting the work that Bryan has done into macros, and polished it up. Every step that's there is stuff that Bryan has decided is necessary. > - if %ghc_autotools is necessary, can the -p option be made optional? What should the default be? > I attach an (untested) which cleans up the macro file a bit. I've attached that to the bug report to add them to GHC. > >> * this file detection stuff is scary >> ** I've put it into a series of macros and documented it > > Ok, that might be useful. :) > >> * this register stuff looks kinky >> ** for starters, it's needed so the compiler knows where to look for >> certain packages >> ** it's been converted to a bunch of macros > > Less worried about that than I used to be. > Again the macros don't really buy much. > > I don't quite understand %ghc_preinst_script and %ghc_postun_script: why do > we need them? Bryan answered this. > >> I also think that if we can make this any more simple, then the only >> thing that cabal-rpm really really needs to do is detect if a package >> is a library, binary, or both, and then fill in some of the >> dependencies automatically, which it's not clever enough yet to do >> properly anyways. We may just need to create a few rpm templates, and >> be done with it. > > Yes, maybe. > >> Anyways, I present the guidelines once more for review. I will try to >> comandeer the help of the people in the SIG to start putting together >> a repo of packages using these macros. The deadline for the F10 >> feature is coming up soon, and I want to have it in a relatively >> stable shape, even though we have time to fine tune the details later. > > We really need to get some packages in the queue reviewed first to check the > sanity of the draft. And IMHO better to use KISS than too much > overengineering. We can add more macros if necessary after more experience > at a later revision. I have a couple of volunteers. Gotta follow up on this. -Yaakov From tibbs at math.uh.edu Wed Aug 27 22:58:01 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Aug 2008 17:58:01 -0500 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> Message-ID: >>>>> "YN" == Yaakov Nemoy writes: YN> I have a couple of volunteers. Gotta follow up on this. Well, perhaps you're unaware, but the draft has passed FPC and a few hours ago passed FESCo and will become official next week unless significant objections are raised. Of course, we need those macros in GHC before things will actually build, and I don't think all of the submitted packages actually conform to the approved draft so there may be a bit of work before they can pass a review. - J< From michel.sylvan at gmail.com Wed Aug 27 23:47:31 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 27 Aug 2008 19:47:31 -0400 Subject: [Fedora-packaging] Re: Game data packaging In-Reply-To: References: <48B321E1.5@hhs.nl> Message-ID: 2008/8/27 Marcin Zaj?czkowski : > On 2008-08-26 23:37, Michel Salim wrote: >> 2008/8/25 Marcin Zaj?czkowski : >>> On 2008-08-25 23:19, Hans de Goede wrote: >>>> Marcin Zaj?czkowski wrote: >>> (...) >>>>> I'm currently preparing package for one small game. It uses standard >>>>> automake. Game assumes that its data will be in $datadir/games/gamename >>>>> and there is no easy way to change it (except patching configure.in). I >>>>> checked my system and there is only one game (gbrainy) with data in >>>>> /usr/share/games(/gbrainy). >>>>> I would like to ask is there any advise to put game data in games subdir >>>>> or it should be treated as a normal application? >>>> It should be treated as a normal application, so please patch configure >>> Thanks guys for the quick answers. >>> >>> I missed a link to SIG pages from Package Maintainers page. >>> >> While you're at it, could you file a bug against gbrainy? > > Sure. > https://bugzilla.redhat.com/show_bug.cgi?id=460353 > pychess had the same problem; fixed in the update that's currently pending. -- Michel Salim http://hircus.jaiku.com/ From petersen at redhat.com Wed Aug 27 23:55:09 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 28 Aug 2008 09:55:09 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> Message-ID: <48B5E95D.7070400@redhat.com> Jason L Tibbitts III ????????: >>>>>> "YN" == Yaakov Nemoy writes: > > YN> I have a couple of volunteers. Gotta follow up on this. > > Well, perhaps you're unaware, but the draft has passed FPC and a few > hours ago passed FESCo and will become official next week unless > significant objections are raised. Sigh, how is that possible when we are still discussing the details? > Of course, we need those macros in > GHC before things will actually build, and I don't think all of the > submitted packages actually conform to the approved draft so there may > be a bit of work before they can pass a review. I really wanted to have the horse in front of the cart... Jens From loupgaroublond at gmail.com Wed Aug 27 23:56:42 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 27 Aug 2008 19:56:42 -0400 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> Message-ID: <7f692fec0808271656q1e69e21bs3f7d7beda8118b2a@mail.gmail.com> On Wed, Aug 27, 2008 at 6:58 PM, Jason L Tibbitts III wrote: >>>>>> "YN" == Yaakov Nemoy writes: > > YN> I have a couple of volunteers. Gotta follow up on this. > > Well, perhaps you're unaware, but the draft has passed FPC and a few > hours ago passed FESCo and will become official next week unless > significant objections are raised. Of course, we need those macros in > GHC before things will actually build, and I don't think all of the > submitted packages actually conform to the approved draft so there may > be a bit of work before they can pass a review. I'm really happy to hear this. I've already opened a bug for this. There are workarounds, but none of them are an optimal situation for the likes of Koji. -Yaakov From tibbs at math.uh.edu Thu Aug 28 00:11:34 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Aug 2008 19:11:34 -0500 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B5E95D.7070400@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> Message-ID: >>>>> "JP" == Jens Petersen writes: JP> Sigh, how is that possible when we are still discussing the JP> details? Because the draft was submitted to us as complete, and we voted on it. If someone didn't want us to vote on it, it would have been nice if someone had let us know. It's been on the schedule for a long time, and only yesterday were we able to assemble a quorum. - J< From petersen at redhat.com Thu Aug 28 00:26:35 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 28 Aug 2008 10:26:35 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> Message-ID: <48B5F0BB.2020908@redhat.com> Hi Jason, > Because the draft was submitted to us as complete, and we voted on it. I understood that it was submitted as a draft for comments... > If someone didn't want us to vote on it, it would have been nice > if someone had let us know. I thought that was what this discussion was about: https://www.redhat.com/archives/fedora-packaging/2008-August/thread.html#00040 Thanks for the headsup anyway. :) Jens From loupgaroublond at gmail.com Thu Aug 28 01:00:01 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 27 Aug 2008 21:00:01 -0400 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B5F0BB.2020908@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> Message-ID: <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> On Wed, Aug 27, 2008 at 8:26 PM, Jens Petersen wrote: > Hi Jason, > >> Because the draft was submitted to us as complete, and we voted on it. > > I understood that it was submitted as a draft for comments... Long ago, i got tired of submitting drafts for comments to have to wait. I took spot's advice and just submitted them for review and comment simultaneously. The principle idea was that I put a deadline on the commenting period, and if there were no comments by a certain time, then it would go straight to review. This way, two groups of people got a chance to look at the drafts at the same time. Finally, it went for a review by the Committee, and they made their comments. We also discussed your comments. I addressed their comments, which was the final request for review. Like I said (accidentally offlist), it's not set in stone either, I'm still listening. -Yaakov From tcallawa at redhat.com Thu Aug 28 02:18:28 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 27 Aug 2008 22:18:28 -0400 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> Message-ID: <1219889908.17806.29.camel@localhost.localdomain> On Wed, 2008-08-27 at 21:00 -0400, Yaakov Nemoy wrote: > Long ago, i got tired of submitting drafts for comments to have to > wait. I took spot's advice and just submitted them for review and > comment simultaneously. We can always change and improve guidelines. It doesn't have to be perfect to pass, the FPC will make suggestions and improvements (see the Font drafts that we revised) on most drafts, and only completely reject items that we disagree with entirely. In scenarios like "programming language $FOO", the FPC is not going to be the experts, we're going to generally trust the people who are. What we're looking for is that the guideline draft is: A) As simple as possible B) As consistent with the rest of Fedora as possible C) As well documented as possible D) Accompanied with thorough example specs E) Something that enables any Fedora contributor to do a review without being an expert in that language ~spot From petersen at redhat.com Thu Aug 28 07:23:11 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 28 Aug 2008 17:23:11 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> Message-ID: <48B6525F.8050900@redhat.com> Hi, Bryan O'Sullivan ????????: > Frankly, I think that the current version of the guidelines is fine. > It's much better to have something not quite perfect where we can make > progress than to be permanently stuck. So moving forwards with what we > have suits me. I finally took a deep look at cabal-rpm (never actually used it before!;) and realised that that is largely the source of all my problems with the current guidelines... Below is a patch against darcs head which backports most of my changes to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we really don't need to add rpm macros IMHO. Thanks for all the comments. Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: cabal-rpm-fedora.patch Type: application/mbox Size: 10937 bytes Desc: not available URL: From fedora at krishnan.cc Thu Aug 28 08:16:15 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 01:16:15 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B6525F.8050900@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48B6525F.8050900@redhat.com> Message-ID: <200808280116.15960.fedora@krishnan.cc> > If we're using cabal-rpm for packaging > then we really don't need to add rpm macros IMHO. I am very much in favor of having good set of base macros (under /etc/rpm/). I have developed some simple rpms using the macros posted by Yaakov and Jens (which needed to be tweaked a bit), and was quite happy with the results. I will share those in the following email. -Rajesh On 2008-08-28-Thu 12:23:11 am Jens Petersen wrote: > Hi, > > Bryan O'Sullivan ????????: > > Frankly, I think that the current version of the guidelines is fine. > > It's much better to have something not quite perfect where we can make > > progress than to be permanently stuck. So moving forwards with what we > > have suits me. > > I finally took a deep look at cabal-rpm (never actually used it > before!;) and realised that that is largely the source of all my > problems with the current guidelines... > > Below is a patch against darcs head which backports most of my changes > to the guidelines to cabal-rpm. If we're using cabal-rpm for packaging > then we really don't need to add rpm macros IMHO. > > Thanks for all the comments. > > Jens From lists at timj.co.uk Thu Aug 28 14:08:15 2008 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 28 Aug 2008 15:08:15 +0100 Subject: [Fedora-packaging] Calling graphical tools generically e.g. text editor Message-ID: <48B6B14F.2070405@timj.co.uk> I package RapidSVN, a GUI application which acts as an interface to a Subversion repository. Although it has quite a lot of functionality built-in, it relies on external software to perform some functions, in particular: - a text editor e.g. gedit - a diff viewer of some sort (ideally graphical e.g. meld) - a graphical directory browser (e.g. nautilus) Currently, these require manual configuration by the user. It would be nice if they worked "out of the box" and respected the user's normal desktop preferences (including respecting different desktop environments - GNOME/KDE/other etc.). I'm not aware of a "clean" way of doing this. Is there any generic command which means "run the user's preferred text editor for the current environment"? Any other bright ideas about how this might be achieved or partially achieved? Bug #459909 refers to this problem. Thanks for any input, Tim From rdieter at math.unl.edu Thu Aug 28 14:32:16 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 28 Aug 2008 09:32:16 -0500 Subject: [Fedora-packaging] Calling graphical tools generically e.g. text editor In-Reply-To: <48B6B14F.2070405@timj.co.uk> References: <48B6B14F.2070405@timj.co.uk> Message-ID: <48B6B6F0.3070505@math.unl.edu> Tim Jackson wrote: > I package RapidSVN, a GUI application which acts as an interface to a > Subversion repository. Although it has quite a lot of functionality > built-in, it relies on external software to perform some functions, in > particular: > > - a text editor e.g. gedit > - a diff viewer of some sort (ideally graphical e.g. meld) > - a graphical directory browser (e.g. nautilus) > > Currently, these require manual configuration by the user. It would be > nice if they worked "out of the box" and respected the user's normal > desktop preferences (including respecting different desktop environments > - GNOME/KDE/other etc.). I'm not aware of a "clean" way of doing this. > Is there any generic command which means "run the user's preferred text > editor for the current environment"? Any other bright ideas about how > this might be achieved or partially achieved? You could consider using xdg-open (from xdg-utils), which is a command-line utility for this kind of thing. It's purpose is to open files/urls using the default app of the current desktop environment (kde, gnome, whatever). -- Rex From pertusus at free.fr Thu Aug 28 14:44:43 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Aug 2008 16:44:43 +0200 Subject: [Fedora-packaging] Calling graphical tools generically e.g. text editor In-Reply-To: <48B6B6F0.3070505@math.unl.edu> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> Message-ID: <20080828144443.GH3417@free.fr> On Thu, Aug 28, 2008 at 09:32:16AM -0500, Rex Dieter wrote: > Tim Jackson wrote: >> I package RapidSVN, a GUI application which acts as an interface to a >> Subversion repository. Although it has quite a lot of functionality >> built-in, it relies on external software to perform some functions, in >> particular: >> >> - a text editor e.g. gedit >> - a diff viewer of some sort (ideally graphical e.g. meld) >> - a graphical directory browser (e.g. nautilus) >> > You could consider using xdg-open (from xdg-utils), which is a > command-line utility for this kind of thing. It's purpose is to open > files/urls using the default app of the current desktop environment > (kde, gnome, whatever). I am not sure that it covers what is wanted here. With xdg-open, it is likely that on text an editor is opened, but it could also be a viewer. For the diff I don't know. But for directory browsing, I am not sure that it will work, on my system, it uses kdesvn because it registered MimeType=inode/directory; Maybe it is just that inode/directory should be reserved for directory browsers, and text for editors and not viewers. -- Pat From rdieter at math.unl.edu Thu Aug 28 14:46:15 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 28 Aug 2008 09:46:15 -0500 Subject: [Fedora-packaging] Calling graphical tools generically e.g. text editor In-Reply-To: <20080828144443.GH3417@free.fr> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> <20080828144443.GH3417@free.fr> Message-ID: <48B6BA37.7060005@math.unl.edu> Patrice Dumas wrote: > On Thu, Aug 28, 2008 at 09:32:16AM -0500, Rex Dieter wrote: >> Tim Jackson wrote: >>> I package RapidSVN, a GUI application which acts as an interface to a >>> Subversion repository. Although it has quite a lot of functionality >>> built-in, it relies on external software to perform some functions, in >>> particular: >>> >>> - a text editor e.g. gedit >>> - a diff viewer of some sort (ideally graphical e.g. meld) >>> - a graphical directory browser (e.g. nautilus) >>> >> You could consider using xdg-open (from xdg-utils), which is a >> command-line utility for this kind of thing. It's purpose is to open >> files/urls using the default app of the current desktop environment >> (kde, gnome, whatever). > > I am not sure that it covers what is wanted here. With xdg-open, it is > likely that on text an editor is opened, but it could also be a viewer. > For the diff I don't know. But for directory browsing, I am not sure > that it will work, on my system, it uses kdesvn because it registered > MimeType=inode/directory; > > Maybe it is just that inode/directory should be reserved for directory > browsers, and text for editors and not viewers. Correct, use of any sort of "default" app, assumes that mimetypes for the opened targets are configured properly. -- Rex From pertusus at free.fr Thu Aug 28 14:57:06 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Aug 2008 16:57:06 +0200 Subject: [Fedora-packaging] Calling graphical tools generically e.g. text editor In-Reply-To: <48B6BA37.7060005@math.unl.edu> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> <20080828144443.GH3417@free.fr> <48B6BA37.7060005@math.unl.edu> Message-ID: <20080828145706.GJ3417@free.fr> On Thu, Aug 28, 2008 at 09:46:15AM -0500, Rex Dieter wrote: > Patrice Dumas wrote: >> >> I am not sure that it covers what is wanted here. With xdg-open, it is >> likely that on text an editor is opened, but it could also be a viewer. >> For the diff I don't know. But for directory browsing, I am not sure >> that it will work, on my system, it uses kdesvn because it registered >> MimeType=inode/directory; >> >> Maybe it is just that inode/directory should be reserved for directory >> browsers, and text for editors and not viewers. > > Correct, use of any sort of "default" app, assumes that mimetypes for > the opened targets are configured properly. But for text, you cannot know if a viewer or an editor is the right one. The most common mimetype seems to be text/plain and it cannot convey this information. I think that in the mailcap format there was such a distinction possible, but I am not sure that it exists for freedesktop stuff. Regarding the inode/directory mimetype, it isn't obvious that kdesvn isn't right. Point is that here there is an action that is wanted in addition to a object type, and xdg-open can only do the somewhat fuzzy action of 'opening'. Maybe we don't need more and consider that the action really associated with opening is in fact set by the application we choose to associate with the mimetype. Put more clearly if we want that 'opening' a text/plain file stands for 'editing' a text/plain file we should just make sure that all the apps associated with text/plain are editors and not viewers. -- Pat From Axel.Thimm at ATrpms.net Thu Aug 28 15:15:16 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 28 Aug 2008 18:15:16 +0300 Subject: [Fedora-packaging] Re: Calling graphical tools generically e.g. text editor In-Reply-To: <20080828145706.GJ3417@free.fr> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> <20080828144443.GH3417@free.fr> <48B6BA37.7060005@math.unl.edu> <20080828145706.GJ3417@free.fr> Message-ID: <20080828151516.GA11937@victor.nirvana> On Thu, Aug 28, 2008 at 04:57:06PM +0200, Patrice Dumas wrote: > On Thu, Aug 28, 2008 at 09:46:15AM -0500, Rex Dieter wrote: > > Patrice Dumas wrote: > >> > >> I am not sure that it covers what is wanted here. With xdg-open, it is > >> likely that on text an editor is opened, but it could also be a viewer. > >> For the diff I don't know. But for directory browsing, I am not sure > >> that it will work, on my system, it uses kdesvn because it registered > >> MimeType=inode/directory; > >> > >> Maybe it is just that inode/directory should be reserved for directory > >> browsers, and text for editors and not viewers. > > > > Correct, use of any sort of "default" app, assumes that mimetypes for > > the opened targets are configured properly. > > But for text, you cannot know if a viewer or an editor is the right one. > The most common mimetype seems to be text/plain and it cannot convey > this information. I think that in the mailcap format there was such a > distinction possible, but I am not sure that it exists for freedesktop > stuff. > > Regarding the inode/directory mimetype, it isn't obvious that kdesvn > isn't right. Point is that here there is an action that is wanted in > addition to a object type, and xdg-open can only do the somewhat fuzzy > action of 'opening'. Maybe we don't need more and consider that the action > really associated with opening is in fact set by the application we > choose to associate with the mimetype. Put more clearly if we want that > 'opening' a text/plain file stands for 'editing' a text/plain file we > should just make sure that all the apps associated with text/plain are > editors and not viewers. xdg-open seems to be geared towards reading/viewing instead of editing. At least the documenation stated for example that xdg-open /tmp/foobar.png Opens the PNG image file /tmp/foobar.png in the user's default image viewing application. E.g. it would probably not open in gimp, but in some lightweight png viewer. Maybe xdg-open needs two modes, read-only and editing? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Aug 28 16:16:05 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 28 Aug 2008 11:16:05 -0500 Subject: [Fedora-packaging] Re: Calling graphical tools generically e.g. text editor In-Reply-To: <20080828151516.GA11937@victor.nirvana> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> <20080828144443.GH3417@free.fr> <48B6BA37.7060005@math.unl.edu> <20080828145706.GJ3417@free.fr> <20080828151516.GA11937@victor.nirvana> Message-ID: <48B6CF45.7060907@math.unl.edu> Axel Thimm wrote: > Maybe xdg-open needs two modes, read-only and editing? I'd argue this is a problem better solved one level higher, via mimetypes (somehow). -- Rex From lists at timj.co.uk Thu Aug 28 16:20:37 2008 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 28 Aug 2008 17:20:37 +0100 Subject: [Fedora-packaging] Calling graphical tools generically e.g. text editor In-Reply-To: <48B6B6F0.3070505@math.unl.edu> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> Message-ID: <48B6D055.3040404@timj.co.uk> Rex Dieter wrote: > You could consider using xdg-open (from xdg-utils), which is a > command-line utility for this kind of thing. It's purpose is to open > files/urls using the default app of the current desktop environment > (kde, gnome, whatever). Thanks Rex, that looks like exactly what I needed. Tim From lists at timj.co.uk Thu Aug 28 16:21:44 2008 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 28 Aug 2008 17:21:44 +0100 Subject: [Fedora-packaging] Re: Calling graphical tools generically e.g. text editor In-Reply-To: <20080828151516.GA11937@victor.nirvana> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> <20080828144443.GH3417@free.fr> <48B6BA37.7060005@math.unl.edu> <20080828145706.GJ3417@free.fr> <20080828151516.GA11937@victor.nirvana> Message-ID: <48B6D098.2010607@timj.co.uk> Axel Thimm wrote: > Maybe xdg-open needs two modes, read-only and editing? Sounds like it to me. I filed a bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=17339 Tim From loupgaroublond at gmail.com Thu Aug 28 18:12:05 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 28 Aug 2008 14:12:05 -0400 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B6525F.8050900@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B5E95D.7070400@redhat.com> <48B5F0BB.2020908@redhat.com> <7f692fec0808271800m1fe4e53fy37a17c8f49694040@mail.gmail.com> <48B6525F.8050900@redhat.com> Message-ID: <7f692fec0808281112x7bfe5c8bjbb4770aacab600f8@mail.gmail.com> On Thu, Aug 28, 2008 at 3:23 AM, Jens Petersen wrote: > Hi, > > Bryan O'Sullivan ????????: >> >> Frankly, I think that the current version of the guidelines is fine. >> It's much better to have something not quite perfect where we can make >> progress than to be permanently stuck. So moving forwards with what we >> have suits me. > > I finally took a deep look at cabal-rpm (never actually used it before!;) > and realised that that is largely the source of all my problems with the > current guidelines... > > Below is a patch against darcs head which backports most of my changes to > the guidelines to cabal-rpm. If we're using cabal-rpm for packaging then we > really don't need to add rpm macros IMHO. > I want to move away from cabal-rpm actually. The biggest pro for the macros is that we need the code to make sense to other reviewers that are not experienced with this. Any time a package needs to do something using something other than one of the macros, then we can have an expert come in an evaluate it. Another reason for using the macros is that changes only need to be made to one place. While doing the guidelines, I had to make a number of changes to cabal-rpm, and were we not to use macros, every change to cabal-rpm would have to be backported to the packages in Fedora. I'm going to put together some templates today. -Yaakov From fedora at krishnan.cc Thu Aug 28 18:24:48 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Thu, 28 Aug 2008 11:24:48 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <200808280116.15960.fedora@krishnan.cc> Message-ID: <200808281124.49306.fedora@krishnan.cc> Bryan, I have forked cabal-rpm (with due credits to you, and the code is still GPL) that does generation of the Fedora specific SPEC file only, with the new macros. I chose to do that because there were too many changes I needed to get some things right, and get rid of other stuff (like executing rpmbuild) that were irrelevant for my purposes. I would publish the code once it becomes half stable and somewhat working. Please don't take this otherwise, as your code is absolutely great Haskell work and I learned some finer Haskell coding styles while studying your code. -Rajesh On 2008-08-28-Thu 06:44:05 am Bryan O'Sullivan wrote: > On Thu, Aug 28, 2008 at 1:16 AM, Rajesh Krishnan wrote: > >> If we're using cabal-rpm for packaging > >> then we really don't need to add rpm macros IMHO. > > > > I am very much in favor of having good set of base macros (under > > /etc/rpm/). > > I like to have both the macros and cabal-rpm, where the latter assumes > the presence of the former. From Axel.Thimm at ATrpms.net Thu Aug 28 18:59:41 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 28 Aug 2008 21:59:41 +0300 Subject: [Fedora-packaging] Re: Calling graphical tools generically e.g. text editor In-Reply-To: <48B6CF45.7060907@math.unl.edu> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> <20080828144443.GH3417@free.fr> <48B6BA37.7060005@math.unl.edu> <20080828145706.GJ3417@free.fr> <20080828151516.GA11937@victor.nirvana> <48B6CF45.7060907@math.unl.edu> Message-ID: <20080828185941.GB22094@victor.nirvana> On Thu, Aug 28, 2008 at 11:16:05AM -0500, Rex Dieter wrote: > Axel Thimm wrote: > >> Maybe xdg-open needs two modes, read-only and editing? Add a third one as "ask user which one of the N editors/viewers to use, if there are more than one registered" (e.g. not only the preferred one, see also below). > I'd argue this is a problem better solved one level higher, via > mimetypes (somehow). You mean that apps register as png/viewer-only and png/editor for example? Actually mimetypes are for describing the data only, so the extra information for the applications ability to view/edit would have to be encoded differently. But still if a file browser just sees some file (say a png file) and one double clicks on it, if it just starts xdg-open it will not be able to pass on what the user wants to do, view or edit. Windows (TM) seems to have a default of "open as in viewing" and a non-default (with Shift?) as "open as in editing". I think there is even an "ask the user which ones of the 100 png viewer to use". Anyone know how OS X solves this? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Aug 28 19:09:44 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 28 Aug 2008 22:09:44 +0300 Subject: [Fedora-packaging] Re: Calling graphical tools generically e.g. text editor In-Reply-To: <20080828185941.GB22094@victor.nirvana> References: <48B6B14F.2070405@timj.co.uk> <48B6B6F0.3070505@math.unl.edu> <20080828144443.GH3417@free.fr> <48B6BA37.7060005@math.unl.edu> <20080828145706.GJ3417@free.fr> <20080828151516.GA11937@victor.nirvana> <48B6CF45.7060907@math.unl.edu> <20080828185941.GB22094@victor.nirvana> Message-ID: <20080828190944.GC22094@victor.nirvana> On Thu, Aug 28, 2008 at 09:59:41PM +0300, Axel Thimm wrote: > On Thu, Aug 28, 2008 at 11:16:05AM -0500, Rex Dieter wrote: > > Axel Thimm wrote: > > > >> Maybe xdg-open needs two modes, read-only and editing? > > Add a third one as "ask user which one of the N editors/viewers to > use, if there are more than one registered" (e.g. not only the > preferred one, see also below). > > > I'd argue this is a problem better solved one level higher, via > > mimetypes (somehow). > > You mean that apps register as png/viewer-only and png/editor for > example? Actually mimetypes are for describing the data only, so the > extra information for the applications ability to view/edit would have > to be encoded differently. > > But still if a file browser just sees some file (say a png file) and > one double clicks on it, if it just starts xdg-open it will not be > able to pass on what the user wants to do, view or edit. > > Windows (TM) seems to have a default of "open as in viewing" and a > non-default (with Shift?) as "open as in editing". I think there is > even an "ask the user which ones of the 100 png viewer to use". Anyone > know how OS X solves this? BTW looks like gnome has this already sorted out: http://developer.gnome.org/doc/whitepapers/SystemConfig/mime-info.html applications register with two different keys: view/open. There are even fm-view/fm-open for file managers and even a convert-to-ascii variant. Maybe xgd has similar functionality? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From philipp_subx at redfish-solutions.com Thu Aug 28 20:43:15 2008 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 28 Aug 2008 13:43:15 -0700 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? Message-ID: <48B70DE3.60706@redfish-solutions.com> I was working on bug 452636 ( https://bugzilla.redhat.com/show_bug.cgi?id=452636 ), and reached an impasse. One of my last reviews (from Joe Orton) said: > non-formal review: > > > > > > 4) Source: http://apache.webthing.com/mod_proxy_html/mod_proxy_html.tgz > > > is bad - do upstream not provide versioned URLs? > > > > > Unfortunately, they do not. > > > upstream should be educated then ;) > > You'll need to work around that and version the tarball manually, I think this > is covered in the wiki somewhere. > Well, I've (a) tried to get the owners to rename the tarball with an embedded version number, so far without success, and (b) went looking through the maintainers wiki on how to handle cases where the tarball isn't versioned (and it must be done manually) but didn't find it. Can someone point me in the correct direction? Thanks, -Philip From tibbs at math.uh.edu Thu Aug 28 22:49:28 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Aug 2008 17:49:28 -0500 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: <48B70DE3.60706@redfish-solutions.com> References: <48B70DE3.60706@redfish-solutions.com> Message-ID: >>>>> "PP" == Philip Prindeville writes: PP> Well, I've (a) tried to get the owners to rename the tarball with PP> an embedded version number, so far without success, and (b) went PP> looking through the maintainers wiki on how to handle cases where PP> the tarball isn't versioned (and it must be done manually) but PP> didn't find it. You just deal with it the hard way. CVS (or the sources mechanism, at least) has no problems dealing with unversioned upstream source. The burden on the packager is higher but it's not really all that difficult to deal with. It does make upstream source comparisons mostly useless, though, so we lose an important means of verification but this isn't something the maintainer can solve. If you asked upstream and they don't care then you've done what you can do. - J< From philipp_subx at redfish-solutions.com Fri Aug 29 01:57:03 2008 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 28 Aug 2008 18:57:03 -0700 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: References: <48B70DE3.60706@redfish-solutions.com> Message-ID: <48B7576F.3070802@redfish-solutions.com> Jason L Tibbitts III wrote: >>>>>> "PP" == Philip Prindeville writes: >>>>>> > > PP> Well, I've (a) tried to get the owners to rename the tarball with > PP> an embedded version number, so far without success, and (b) went > PP> looking through the maintainers wiki on how to handle cases where > PP> the tarball isn't versioned (and it must be done manually) but > PP> didn't find it. > > You just deal with it the hard way. CVS (or the sources mechanism, at > least) has no problems dealing with unversioned upstream source. The > burden on the packager is higher but it's not really all that > difficult to deal with. It does make upstream source comparisons > mostly useless, though, so we lose an important means of verification > but this isn't something the maintainer can solve. > > If you asked upstream and they don't care then you've done what you > can do. > > - J< > Yeah, about that... they don't seem to be using CVS upstream... If they're using SVN, then they don't publish a public interface. -Philip From tibbs at math.uh.edu Fri Aug 29 02:20:39 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Aug 2008 21:20:39 -0500 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: <48B7576F.3070802@redfish-solutions.com> References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> Message-ID: >>>>> "PP" == Philip Prindeville writes: PP> Yeah, about that... they don't seem to be using CVS upstream... PP> If they're using SVN, then they don't publish a public interface. I was talking about our CVS. You can do "make new-sources" with a new tarball that has the same name and the system won't be confused (because it differentiates by checksum). The bottom line is that if upstream doesn't version their tarballs, you can simply upload them to the buildsys and nothing will break. So its really your choice as to whether you want to do some sort of local renaming or not. Personally I wouldn't, since it really doesn't do much good. - J< From michel.sylvan at gmail.com Fri Aug 29 02:24:59 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 28 Aug 2008 22:24:59 -0400 Subject: [Fedora-packaging] Simple cvs extras suggestion In-Reply-To: <200808132128.16055.opensource@till.name> References: <20080812172625.12e521ea@solitude.devel.redhat.com> <200808132128.16055.opensource@till.name> Message-ID: On Wed, Aug 13, 2008 at 3:28 PM, Till Maas wrote: > On Tue August 12 2008, Robin Norwood wrote: >> Hi, >> >> With the goal of opening up ACLs on 'most' packages, I'd like to >> suggest that the New Package CVS Request template on this page: >> >> https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure >> >> Change the last line from: >> >> Cvsextras Commits: >> >> To: >> >> Cvsextras Commits: yes > > Afaik the group is now called packager, therefore it probably be > > | Packager Commits: yes > But packager commits: no is rather useless, surely, since that will override the access of people who are registered to co-maintain the package in pkgdb? Perhaps, as Toshio said, the package maintainer could just go to pkgdb to change the value if needed. It could even be useful at times -- say you are heavily reworking a package, and don't want comaintainers to butt in for a while. -- Michel Salim http://hircus.jaiku.com/ From tibbs at math.uh.edu Fri Aug 29 02:50:07 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Aug 2008 21:50:07 -0500 Subject: [Fedora-packaging] Simple cvs extras suggestion In-Reply-To: References: <20080812172625.12e521ea@solitude.devel.redhat.com> <200808132128.16055.opensource@till.name> Message-ID: >>>>> "MS" == Michel Salim writes: MS> But packager commits: no is rather useless, surely, since that MS> will override the access of people who are registered to MS> co-maintain the package in pkgdb? Seems to me that the message you replied to is quite old. I think if you check the page you'll note that it hasn't mentioned CVSextras commits or packager commits for a while now. - J< From petersen at redhat.com Fri Aug 29 04:28:41 2008 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Aug 2008 14:28:41 +1000 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> Message-ID: <48B77AF9.7010008@redhat.com> (Late followup since I spent most of yesterday working on a cabal-rpm patch.) Yaakov Nemoy ????????: >>> * %buildsubdir is not a common way of doing things >>> ** we need this macro in the install phase to get at the working dir >>> we used to compile the package. >> This is not haskell specific and should really not be needed. >> Let's try to get rid of it. > > It's needed for the macros that do file detection later on. Once we > cd into the buildroot, we need a way of accessing the old dir we used > to compile the package. Therefore, I've put it in a macro, and both > sets of macros are mandatory. If you have a better solution, please > fix it. No it is not needed: you could use ${RPM_BUILD_DIR} for that if necessary (however see also the end of this mail). >> But how are packages supposed to get these macros? >> Surely each package is not going to include all of >> http://ynemoy.fedorapeople.org/haskell/macros.ghc ? > > That file is going to be packaged with ghc itself. I've submitted the > following bug. > https://bugzilla.redhat.com/show_bug.cgi?id=460304 Do any other packages (languages) in Fedora provide rpm macros? One of the things I always liked about fedora is that our spec files are self-contained unlike some other distros. Are we moving anyway from that? Also housing the macros in ghc means that if we need to change them then ghc needs to be rebuild which is a bit expensive - though hopefully that would be not necessary too often. >> The macros are not really that ghc specific: they should be prefixed cabal >> not ghc. > > Technically no, but I want to differentiate between what the > theoretical command might be for foo haskell compiler, and what > nuances there might be between compilers. I would prefer just a few macros suitable for cabal that would work across ghc, hugs, etc, than something very specific to ghc. >> IMHO some of it seems to be overkill. > > How so? For the most part, i'm converting the work that Bryan has > done into macros, and polished it up. Every step that's there is > stuff that Bryan has decided is necessary. I created some patches to cleanup cabal-rpm's output. I wish you had made clear earlier that that was where all this was coming from... if I had known that I could have cleaned it up much earlier... As I noted yesterday: I finally tried cabal-rpm and finally realised where all those macros are coming from. So sorry to Yaakov: it seems most of my quibbles have actually been with cabal-rpm! ;) I think I may submit a cabal-rpm package to fedora so that it can be included. IMHO a couple of self-contained spec templates are still quite sufficient for now and that is the way I am inclined to go. Packaging cabal packages is really not that hard, and to me hiding small incantation in obscure macros really does not buy use much at all. As long as packages follow the templates reviews should be just as straightforward. >> - if %ghc_autotools is necessary, can the -p option be made optional? > What should the default be? Profiling by default? I don't use profile much myself... what do others think? >> I attach an (untested) which cleans up the macro file a bit. > I've attached that to the bug report to add them to GHC. Thanks. There are still more changes that need to be made though. > >> * this file detection stuff is scary > >> ** I've put it into a series of macros and documented it > Ok, that might be useful. :) Has anyone other than me tested them though? The filelist macros in the ghc-X11 review do not work for me, and they seem to be the same as in the current macros... I just submitted a patch for it in ghc-X11 review https://bugzilla.redhat.com/show_bug.cgi?id=426751#c14 now. (Also in my cabal-rpm patches.) Jens From ivazqueznet at gmail.com Fri Aug 29 07:55:48 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 29 Aug 2008 03:55:48 -0400 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> Message-ID: <1219996548.7857.6.camel@ignacio.lan> On Thu, 2008-08-28 at 21:20 -0500, Jason L Tibbitts III wrote: > The bottom line is that if upstream doesn't version their tarballs, you > can simply upload them to the buildsys and nothing will break. So its > really your choice as to whether you want to do some sort of local > renaming or not. Personally I wouldn't, since it really doesn't do > much good. Except when you have different versions of Fedora having different versions of the package. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Fri Aug 29 08:09:22 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 29 Aug 2008 11:09:22 +0300 Subject: [Fedora-packaging] Re: How to handle unversioned upstream tarballs? In-Reply-To: <48B7576F.3070802@redfish-solutions.com> References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> Message-ID: <20080829080922.GD22094@victor.nirvana> On Thu, Aug 28, 2008 at 06:57:03PM -0700, Philip Prindeville wrote: > Jason L Tibbitts III wrote: >>>>>>> "PP" == Philip Prindeville writes: >>>>>>> >> >> PP> Well, I've (a) tried to get the owners to rename the tarball with >> PP> an embedded version number, so far without success, and (b) went >> PP> looking through the maintainers wiki on how to handle cases where >> PP> the tarball isn't versioned (and it must be done manually) but >> PP> didn't find it. >> >> You just deal with it the hard way. CVS (or the sources mechanism, at >> least) has no problems dealing with unversioned upstream source. The >> burden on the packager is higher but it's not really all that >> difficult to deal with. It does make upstream source comparisons >> mostly useless, though, so we lose an important means of verification >> but this isn't something the maintainer can solve. >> >> If you asked upstream and they don't care then you've done what you >> can do. >> >> - J< >> > > Yeah, about that... they don't seem to be using CVS upstream... If > they're using SVN, then they don't publish a public interface. If you are after a date to use as a version number, then use the mtime of the tarball. Get it with wget -N to preserve timestamps (curl has similar options). If the download is broken timestamp-wise (like it is for asterisk/zaptel etc. for example), then use the date of the newest file in the tarball. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rjones at redhat.com Fri Aug 29 08:43:20 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 29 Aug 2008 09:43:20 +0100 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B77AF9.7010008@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <48AE707D.60500@redhat.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B77AF9.7010008@redhat.com> Message-ID: <20080829084320.GA28760@amd.home.annexia.org> On Fri, Aug 29, 2008 at 02:28:41PM +1000, Jens Petersen wrote: > Do any other packages (languages) in Fedora provide rpm macros? One of > the things I always liked about fedora is that our spec files are > self-contained unlike some other distros. Are we moving anyway from > that? The base ocaml package contains a couple of scripts which are then used by all the OCaml packages. https://fedoraproject.org/wiki/Packaging/OCaml#Requires_and_provides The aim is to get these two scripts into upstream RPM eventually, where "eventually" is defined as when we get an upstream OCaml bug that affects these scripts fixed. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From fedora at krishnan.cc Fri Aug 29 10:00:08 2008 From: fedora at krishnan.cc (Rajesh Krishnan) Date: Fri, 29 Aug 2008 03:00:08 -0700 Subject: [Fedora-packaging] Re: [Fedora-haskell-list] Revised Haskell Guidelines 2008.08.13 In-Reply-To: <48B77AF9.7010008@redhat.com> References: <7f692fec0808130801j68486e54r6b791a7c5aeee32c@mail.gmail.com> <7f692fec0808271547g392176e8r1a2f4177ed785abb@mail.gmail.com> <48B77AF9.7010008@redhat.com> Message-ID: <200808290300.08887.fedora@krishnan.cc> > self-contained unlike some other distros. Are we moving anyway from that? > > Also housing the macros in ghc means that if we need to change them then > ghc needs to be rebuild which is a bit expensive - though hopefully that > would be not necessary too often. This thread is getting even more confusing. :-( I think what Yaakov mentioned was that these macros would be used only for compiling Hackage/Cabal packages (and the like) and not for building the GHC compiler itself. Right Yaakov? For now I have decided to use a modified version of Yaakov's original macros.ghc file, and build a test package with it and submit it. Will keep everyone updated in the following mails. -Rajesh On 2008-08-28-Thu 09:28:41 pm Jens Petersen wrote: > (Late followup since I spent most of yesterday working on a cabal-rpm > patch.) > > Yaakov Nemoy ????????: > >>> * %buildsubdir is not a common way of doing things > >>> ** we need this macro in the install phase to get at the working dir > >>> we used to compile the package. > >> > >> This is not haskell specific and should really not be needed. > >> Let's try to get rid of it. > > > > It's needed for the macros that do file detection later on. Once we > > cd into the buildroot, we need a way of accessing the old dir we used > > to compile the package. Therefore, I've put it in a macro, and both > > sets of macros are mandatory. If you have a better solution, please > > fix it. > > No it is not needed: you could use ${RPM_BUILD_DIR} for that if > necessary (however see also the end of this mail). > > >> But how are packages supposed to get these macros? > >> Surely each package is not going to include all of > >> http://ynemoy.fedorapeople.org/haskell/macros.ghc ? > > > > That file is going to be packaged with ghc itself. I've submitted the > > following bug. > > https://bugzilla.redhat.com/show_bug.cgi?id=460304 > > Do any other packages (languages) in Fedora provide rpm macros? One of > the things I always liked about fedora is that our spec files are > self-contained unlike some other distros. Are we moving anyway from that? > > Also housing the macros in ghc means that if we need to change them then > ghc needs to be rebuild which is a bit expensive - though hopefully that > would be not necessary too often. > > >> The macros are not really that ghc specific: they should be prefixed > >> cabal not ghc. > > > > Technically no, but I want to differentiate between what the > > theoretical command might be for foo haskell compiler, and what > > nuances there might be between compilers. > > I would prefer just a few macros suitable for cabal that would work > across ghc, hugs, etc, than something very specific to ghc. > > >> IMHO some of it seems to be overkill. > > > > How so? For the most part, i'm converting the work that Bryan has > > done into macros, and polished it up. Every step that's there is > > stuff that Bryan has decided is necessary. > > I created some patches to cleanup cabal-rpm's output. I wish you had > made clear earlier that that was where all this was coming from... if I > had known that I could have cleaned it up much earlier... > > As I noted yesterday: I finally tried cabal-rpm and finally realised > where all those macros are coming from. So sorry to Yaakov: it seems > most of my quibbles have actually been with cabal-rpm! ;) > > I think I may submit a cabal-rpm package to fedora so that it can be > included. > > IMHO a couple of self-contained spec templates are still quite > sufficient for now and that is the way I am inclined to go. Packaging > cabal packages is really not that hard, and to me hiding small > incantation in obscure macros really does not buy use much at all. As > long as packages follow the templates reviews should be just as > straightforward. > > >> - if %ghc_autotools is necessary, can the -p option be made optional? > > > > What should the default be? > > Profiling by default? I don't use profile much myself... what do others > think? > > >> I attach an (untested) which cleans up the macro file a bit. > > > > I've attached that to the bug report to add them to GHC. > > Thanks. There are still more changes that need to be made though. > > > >> * this file detection stuff is scary > > >> ** I've put it into a series of macros and documented it > > > > Ok, that might be useful. :) > > Has anyone other than me tested them though? The filelist macros in the > ghc-X11 review do not work for me, and they seem to be the same as in > the current macros... > > I just submitted a patch for it in ghc-X11 review > https://bugzilla.redhat.com/show_bug.cgi?id=426751#c14 > now. (Also in my cabal-rpm patches.) > > Jens > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From tibbs at math.uh.edu Fri Aug 29 11:55:04 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Aug 2008 06:55:04 -0500 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: <1219996548.7857.6.camel@ignacio.lan> References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> <1219996548.7857.6.camel@ignacio.lan> Message-ID: >>>>> "IV" == Ignacio Vazquez-Abrams writes: IV> Except when you have different versions of Fedora having different IV> versions of the package. I fail to see what difference that makes. Of course you version the package itself. - J< From ivazqueznet at gmail.com Fri Aug 29 12:04:37 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 29 Aug 2008 08:04:37 -0400 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> <1219996548.7857.6.camel@ignacio.lan> Message-ID: <1220011477.7857.15.camel@ignacio.lan> On Fri, 2008-08-29 at 06:55 -0500, Jason L Tibbitts III wrote: > >>>>> "IV" == Ignacio Vazquez-Abrams writes: > > IV> Except when you have different versions of Fedora having different > IV> versions of the package. > > I fail to see what difference that makes. Of course you version the > package itself. Won't they conflict in the lookaside cache? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Aug 29 12:07:44 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Aug 2008 07:07:44 -0500 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: <1220011477.7857.15.camel@ignacio.lan> References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> <1219996548.7857.6.camel@ignacio.lan> <1220011477.7857.15.camel@ignacio.lan> Message-ID: >>>>> "IV" == Ignacio Vazquez-Abrams writes: IV> Won't they conflict in the lookaside cache? No. Check my earlier messages in the thread: files in the lookaside cache are differentiated by checksum. - J< From pertusus at free.fr Fri Aug 29 12:13:21 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 29 Aug 2008 14:13:21 +0200 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> Message-ID: <20080829121321.GA3140@free.fr> On Thu, Aug 28, 2008 at 09:20:39PM -0500, Jason L Tibbitts III wrote: > > The bottom line is that if upstream doesn't version their tarballs, you > can simply upload them to the buildsys and nothing will break. So its > really your choice as to whether you want to do some sort of local > renaming or not. Personally I wouldn't, since it really doesn't do > much good. I think that it is best left to the packager choice, but in my opinion it helps knowing what source archive is packaged to rename locally and have the timestamp in package name. The downside is that automatic source detection, and automatic download doesn't work anymore. -- Pat From denis at poolshark.org Fri Aug 29 12:14:47 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 29 Aug 2008 14:14:47 +0200 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> <1219996548.7857.6.camel@ignacio.lan> <1220011477.7857.15.camel@ignacio.lan> Message-ID: <48B7E837.4000006@poolshark.org> Jason L Tibbitts III wrote: >>>>>> "IV" == Ignacio Vazquez-Abrams writes: > > IV> Won't they conflict in the lookaside cache? > > No. Check my earlier messages in the thread: files in the lookaside > cache are differentiated by checksum. Still, the lookaside can only keep one version of the tarball right ?, which would imply all branches of the package must be at the same version also. That doesn't manageable. From tibbs at math.uh.edu Fri Aug 29 12:46:31 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Aug 2008 07:46:31 -0500 Subject: [Fedora-packaging] How to handle unversioned upstream tarballs? In-Reply-To: <48B7E837.4000006@poolshark.org> References: <48B70DE3.60706@redfish-solutions.com> <48B7576F.3070802@redfish-solutions.com> <1219996548.7857.6.camel@ignacio.lan> <1220011477.7857.15.camel@ignacio.lan> <48B7E837.4000006@poolshark.org> Message-ID: >>>>> "DL" == Denis Leroy writes: DL> Still, the lookaside can only keep one version of the tarball DL> right ? No. It differentiates by checksum: one tarball per name/checksum pair. If you alter the tarball without renaming and re-upload it, the old one will still be in the lookaside. I'm not sure what else I can say to convince folks that yes, the lookaside really can handle multiple different tarballs with the same name. Would you like to see the directory structure? It looks like: package-name/ tarball-name/ tarball-checksum1/ tarball-name tarball-checksum2/ tarball-name For example, the auccu pacjkage has a tarball that changed: aiccu_20070107.tar.gz is present with two different checksums: $ ls -R aiccu//aiccu_20070107.tar.gz/ aiccu//aiccu_20070107.tar.gz/: 60c203fa33cad3db9fba2a871e3d9381 67a6d55ef2d6e88a3f17bcb5eec02c61 aiccu//aiccu_20070107.tar.gz/60c203fa33cad3db9fba2a871e3d9381: aiccu_20070107.tar.gz aiccu//aiccu_20070107.tar.gz/67a6d55ef2d6e88a3f17bcb5eec02c61: aiccu_20070107.tar.gz >From the script that runs when you upload files: file_dest = "%s/%s/%s/%s/%s" % (my_topdir, NAME, FILENAME, MD5SUM, FILENAME) - J<