From jwilson at redhat.com Sun Apr 1 06:28:21 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 01 Apr 2007 02:28:21 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <20070331232007.GA9963@osiris.silug.org> References: <460AC5BD.6090107@redhat.com> <20070331232007.GA9963@osiris.silug.org> Message-ID: <460F5105.9030300@redhat.com> Steven Pritchard wrote: > On Wed, Mar 28, 2007 at 03:45:01PM -0400, Jarod Wilson wrote: >> I'd like to package up Maia Mailguard, and the license appears to be >> original BSD (advertising clause included) with a branding extension >> added. Thoughts? >> >> http://www.maiamailguard.org/license.php > > Isn't Maia a fork of amavisd-new? Pretty much, yeah. > If so, how can its license be anything other than than GPL? Good question... I'll raise that with the authors. -- Jarod Wilson jwilson at redhat.com From ssorce at redhat.com Mon Apr 2 12:48:38 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Apr 2007 08:48:38 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <460F5105.9030300@redhat.com> References: <460AC5BD.6090107@redhat.com> <20070331232007.GA9963@osiris.silug.org> <460F5105.9030300@redhat.com> Message-ID: <1175518119.3272.1.camel@willson> On Sun, 2007-04-01 at 02:28 -0400, Jarod Wilson wrote: > Steven Pritchard wrote: > > On Wed, Mar 28, 2007 at 03:45:01PM -0400, Jarod Wilson wrote: > >> I'd like to package up Maia Mailguard, and the license appears to be > >> original BSD (advertising clause included) with a branding extension > >> added. Thoughts? > >> > >> http://www.maiamailguard.org/license.php > > > > Isn't Maia a fork of amavisd-new? > > Pretty much, yeah. > > > If so, how can its license be anything other than than GPL? I don't think amavisd-new had any web interface. That part of the license may apply only to the web interface. > Good question... I'll raise that with the authors. Yes, and it would be nice if the author would release it under pure GPL, or maybe the Affero GPL ? From jwilson at redhat.com Tue Apr 3 01:51:55 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 02 Apr 2007 21:51:55 -0400 Subject: [Fedora-packaging] Is this license okay for a fedora package? In-Reply-To: <1175518119.3272.1.camel@willson> References: <460AC5BD.6090107@redhat.com> <20070331232007.GA9963@osiris.silug.org> <460F5105.9030300@redhat.com> <1175518119.3272.1.camel@willson> Message-ID: <4611B33B.2000108@redhat.com> Simo Sorce wrote: > On Sun, 2007-04-01 at 02:28 -0400, Jarod Wilson wrote: >> Steven Pritchard wrote: >>> On Wed, Mar 28, 2007 at 03:45:01PM -0400, Jarod Wilson wrote: >>>> I'd like to package up Maia Mailguard, and the license appears to be >>>> original BSD (advertising clause included) with a branding extension >>>> added. Thoughts? >>>> >>>> http://www.maiamailguard.org/license.php >>> Isn't Maia a fork of amavisd-new? >> Pretty much, yeah. >> >>> If so, how can its license be anything other than than GPL? > > I don't think amavisd-new had any web interface. > That part of the license may apply only to the web interface. That is indeed the case. >> Good question... I'll raise that with the authors. > > Yes, and it would be nice if the author would release it under pure GPL, > or maybe the Affero GPL ? That would be a "not likely". :) http://www.renaissoft.com/pipermail/maia-users/2007-January/008699.html Seems this won't fly as an official Fedora package. No biggie, the Maia folks have offered to host it or link to it or whatever, wherever it winds up. -- Jarod Wilson jwilson at redhat.com From ville.skytta at iki.fi Tue Apr 3 10:42:24 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 3 Apr 2007 13:42:24 +0300 Subject: [Fedora-packaging] Hardlinking *.pyc and *.pyo Message-ID: <200704031342.25238.ville.skytta@iki.fi> Hello, Related to recent space saving discussions, I came across PLD's rpm-build-macros package recently, and found that they hardlink identical *.pyc and *.pyo. In a lot of cases, they're the same, and there's some potential for saving some MB "for free", on my FC6 x86_64 box: $ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1 Would save 11116544 The PLD implementation looks like this: # Hardlink binary identical .pyc and .pyo files # (idea by glen pld-linux org) %__spec_install_post_py_hardlink {\ %{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \ [ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \ b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \ if cmp -s "$a" "$b"; then \ ln -f "$a" "$b"; \ fi; \ done \ }; __spec_install_post_py_hardlink } } The use of "cmp" would require diffutils installed. Or the above could be converted to use hardlink instead (which would have to be made sure to be around) or maybe sha1sum (in coreutils, pretty much always around in buildroots). I suppose something like the above could be easily added to redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile or run after it in %__os_install_post. Worth it? Other comments? From fedora at leemhuis.info Tue Apr 3 11:17:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 03 Apr 2007 13:17:15 +0200 Subject: [Fedora-packaging] Hardlinking *.pyc and *.pyo In-Reply-To: <200704031342.25238.ville.skytta@iki.fi> References: <200704031342.25238.ville.skytta@iki.fi> Message-ID: <461237BB.5050700@leemhuis.info> On 03.04.2007 12:42, Ville Skytt? wrote: > Worth it? Other comments? Hehe, sounds interesting. Did you tell the Live-CD guys about it? I'd say they will probably very interested in something like this (they could run hardlink directly for now until we decide what we want to do). CU thl From ville.skytta at iki.fi Tue Apr 3 11:45:37 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 3 Apr 2007 14:45:37 +0300 Subject: [Fedora-packaging] Hardlinking *.pyc and *.pyo In-Reply-To: <461237BB.5050700@leemhuis.info> References: <200704031342.25238.ville.skytta@iki.fi> <461237BB.5050700@leemhuis.info> Message-ID: <200704031445.37318.ville.skytta@iki.fi> On Tuesday 03 April 2007, Thorsten Leemhuis wrote: > On 03.04.2007 12:42, Ville Skytt? wrote: > > Worth it? Other comments? > > Hehe, sounds interesting. Did you tell the Live-CD guys about it? I'd > say they will probably very interested in something like this (they > could run hardlink directly for now until we decide what we want to do). Nope, just brought it up in last week's packaging meeting and now posted here. Feel free to forward. Another thing they could be interested in (again on my FC6 x86_64): $ /usr/sbin/hardlink -ncv /usr/share/doc 2>&1 | tail -n 1 Would save 6692864 (of which COPYING's share is about 3.2M) From Axel.Thimm at ATrpms.net Tue Apr 3 12:01:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Apr 2007 14:01:06 +0200 Subject: [Fedora-packaging] Re: Hardlinking *.pyc and *.pyo In-Reply-To: <200704031342.25238.ville.skytta@iki.fi> References: <200704031342.25238.ville.skytta@iki.fi> Message-ID: <20070403120106.GD29856@neu.nirvana> On Tue, Apr 03, 2007 at 01:42:24PM +0300, Ville Skytt? wrote: > Related to recent space saving discussions, I came across PLD's > rpm-build-macros package recently, and found that they hardlink > identical *.pyc and *.pyo. In a lot of cases, they're the same, > and there's some potential for saving some MB "for free", > on my FC6 x86_64 box: > > $ /usr/sbin/hardlink -ncv /usr/lib*/python2.4 2>&1 | tail -n 1 > Would save 11116544 I get more than twice as much on a typical FC6/x86_64 system: 27275264. That's 26 MB on 166MB total, e.g. saving 16%. # du -sc /usr/lib*/python2.4| tail -n 1 170200 total On another system I get 21MB of 144MB total, e.g about 15%. > The PLD implementation looks like this: > > # Hardlink binary identical .pyc and .pyo files > # (idea by glen pld-linux org) > %__spec_install_post_py_hardlink {\ > %{!?no_install_post_py_hardlink: __spec_install_post_py_hardlink() { \ > [ ! -d "$RPM_BUILD_ROOT" ] || find "$RPM_BUILD_ROOT" -name '*.pyc' | while read a; do \ > b="$(echo $a|sed -e 's/.pyc$/.pyo/')"; \ > if cmp -s "$a" "$b"; then \ > ln -f "$a" "$b"; \ > fi; \ > done \ > }; __spec_install_post_py_hardlink } } > > The use of "cmp" would require diffutils installed. Or the above > could be converted to use hardlink instead (which would have to be made > sure to be around) or maybe sha1sum (in coreutils, pretty much always > around in buildroots). > > I suppose something like the above could be easily added to > redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile > or run after it in %__os_install_post. brp-python-bytecompile sounds like the best spot since the pyc/pyos are created there. Maybe we should ship an improved brp-python-bytecompile in redhat-rpm-config while lobbying rpm upstream to adopt it? > Worth it? Other comments? A 15% space gain (under python) w/o any drawbacks? Always worth it. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 3 15:04:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 3 Apr 2007 17:04:32 +0200 Subject: [Fedora-packaging] Missing today's meeting Message-ID: <20070403150432.GK29856@neu.nirvana> Hi, I won't be able to make the meeting today. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Apr 3 15:42:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 03 Apr 2007 17:42:16 +0200 Subject: [Fedora-packaging] Missing today's meeting In-Reply-To: <20070403150432.GK29856@neu.nirvana> References: <20070403150432.GK29856@neu.nirvana> Message-ID: <1175614937.24401.492.camel@mccallum.corsepiu.local> On Tue, 2007-04-03 at 17:04 +0200, Axel Thimm wrote: > Hi, > > I won't be able to make the meeting today. While we're at it, I'll probably also be missing or at least will have to leave early. Also, I'd appreciate it if the meeting time could be adjusted to DST. The current time-slot (19:00-20:00 CEST) to me significantly increases the likelihood of not being able to join meetings. Ralf From jkeating at redhat.com Tue Apr 3 15:48:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Apr 2007 11:48:08 -0400 Subject: [Fedora-packaging] Missing today's meeting In-Reply-To: <1175614937.24401.492.camel@mccallum.corsepiu.local> References: <20070403150432.GK29856@neu.nirvana> <1175614937.24401.492.camel@mccallum.corsepiu.local> Message-ID: <200704031148.08631.jkeating@redhat.com> On Tuesday 03 April 2007 11:42:16 Ralf Corsepius wrote: > Also, I'd appreciate it if the meeting time could be adjusted to DST. > The current time-slot (19:00-20:00 CEST) to me significantly increases > the likelihood of not being able to join meetings. Whereas adjusting it for DST (making it an hour earlier) significantly increases the likelyhood of me not being able to join as well. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Apr 3 15:49:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 03 Apr 2007 17:49:11 +0200 Subject: [Fedora-packaging] Missing today's meeting In-Reply-To: <200704031148.08631.jkeating@redhat.com> References: <20070403150432.GK29856@neu.nirvana> <1175614937.24401.492.camel@mccallum.corsepiu.local> <200704031148.08631.jkeating@redhat.com> Message-ID: <1175615351.24401.495.camel@mccallum.corsepiu.local> On Tue, 2007-04-03 at 11:48 -0400, Jesse Keating wrote: > On Tuesday 03 April 2007 11:42:16 Ralf Corsepius wrote: > > Also, I'd appreciate it if the meeting time could be adjusted to DST. > > The current time-slot (19:00-20:00 CEST) to me significantly increases > > the likelihood of not being able to join meetings. > > Whereas adjusting it for DST (making it an hour earlier) significantly > increases the likelyhood of me not being able to join as well. Then let's look for a completely different time. Anything earlier than 19:00 CEST (17:00 UTC) would be fine with me. Ralf From tibbs at math.uh.edu Tue Apr 3 17:49:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Apr 2007 12:49:07 -0500 Subject: [Fedora-packaging] Hardlinking *.pyc and *.pyo In-Reply-To: <200704031342.25238.ville.skytta@iki.fi> References: <200704031342.25238.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> I suppose something like the above could be easily added to VS> redhat-rpm-config or rpm, eg. embedded in brp-python-bytecompile VS> or run after it in %__os_install_post. I expect that Python is where most of the savings come from, but it might be worth running something like this to catch duplicated files in any package. The only issue is that we have to be careful to only look within single directories, because we cannot predict where filesystem boundaries will be. - J< From petersen at redhat.com Wed Apr 4 02:22:15 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 04 Apr 2007 12:22:15 +1000 Subject: [Fedora-packaging] font package naming Message-ID: <46130BD7.3070708@redhat.com> Hi, I would like to propose adding the following text to our "Package Naming Guidelines". http://fedoraproject.org/wiki/Packaging/NamingGuidelines ''' == Fonts Packages == Font packages should be named with the upstream name appended with `-fonts`. Examples: {{{ bitmap-fonts dejavu-lgc-fonts ghostscript-fonts urw-fonts xorg-x11-fonts }}} ''' Should the text discuss what to do when the upstream name contains the word "font" already? See https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00794.html and https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00262.html for some recent discussion of -fonts vs fonts- and "-fonts" vs "-font" for singlet font packages. Comments or objections? Jens ps We might even consider renaming some of our "fonts-*" packages to follow this naming scheme for F8. From mwringe at redhat.com Wed Apr 4 19:38:06 2007 From: mwringe at redhat.com (Matt Wringe) Date: Wed, 04 Apr 2007 15:38:06 -0400 Subject: [Fedora-packaging] license for concurrent package In-Reply-To: <1175260830.7124.12.camel@localhost.localdomain> References: <460C7110.2000508@redhat.com> <1175260830.7124.12.camel@localhost.localdomain> Message-ID: <1175715486.553.52.camel@toque.toronto.redhat.com> On Fri, 2007-03-30 at 08:20 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-03-29 at 22:08 -0400, Permaine Cheung wrote: > > Hi, > > > > The concurrent package in core has stated the following (under the Notes > > section of its URL > > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html): > > > > > > 'All classes are released to the public domain and may be used for any > > purpose whatsoever without permission or acknowledgment. Portions of the > > CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted > > from Sun JDK source code. These are copyright of Sun Microsystems, Inc, > > and are used with their kind permission,' (link is > > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.pdf) > > > > And further down from that page it states: > > 'Do I need a license to use it? Can I get one? No!' > > > > Is this okay? > > Yes. Public Domain is acceptable. Right, but is it really public domain with respect to those two other files? > ~spot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Apr 4 20:06:00 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Apr 2007 15:06:00 -0500 Subject: [Fedora-packaging] license for concurrent package In-Reply-To: <1175715486.553.52.camel@toque.toronto.redhat.com> References: <460C7110.2000508@redhat.com> <1175260830.7124.12.camel@localhost.localdomain> <1175715486.553.52.camel@toque.toronto.redhat.com> Message-ID: <1175717160.30872.62.camel@localhost.localdomain> On Wed, 2007-04-04 at 15:38 -0400, Matt Wringe wrote: > On Fri, 2007-03-30 at 08:20 -0500, Tom "spot" Callaway wrote: > > On Thu, 2007-03-29 at 22:08 -0400, Permaine Cheung wrote: > > > Hi, > > > > > > The concurrent package in core has stated the following (under the Notes > > > section of its URL > > > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html): > > > > > > > > > 'All classes are released to the public domain and may be used for any > > > purpose whatsoever without permission or acknowledgment. Portions of the > > > CopyOnWriteArrayList and ConcurrentReaderHashMap classes are adapted > > > from Sun JDK source code. These are copyright of Sun Microsystems, Inc, > > > and are used with their kind permission,' (link is > > > http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.pdf) > > > > > > And further down from that page it states: > > > 'Do I need a license to use it? Can I get one? No!' > > > > > > Is this okay? > > > > Yes. Public Domain is acceptable. > Right, but is it really public domain with respect to those two other > files? That license is just BSD, it doesn't affect the rest of the code. It's still ok. ~spot From chris.stone at gmail.com Thu Apr 5 23:46:45 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 5 Apr 2007 16:46:45 -0700 Subject: [Fedora-packaging] rpm output guidelines Message-ID: Why is my console littered with tons of output when I update selinux-policy-targeted rpm? I get tons of crap spewed out to my console. Aren't there any guidelines to prevent packages from doing this, and if not can we please make some? Wouldn't it be great if all this garbage output went to some place nice like syslog? selinux-policy-target puke: /sbin/restorecon reset /etc/cron.daily/000-delay.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/00webalizer context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/beagle-crawl-system context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/certwatch context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/cups context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/logrotate context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/makewhatis.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/mlocate.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/prelink context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/rpm context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.daily/tmpwatch context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.hourly/mcelog.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.monthly/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.weekly/0anacron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /etc/cron.weekly/makewhatis.cron context system_u:object_r:etc_t:s0->system_u:object_r:bin_t:s0 Do I really need to know all this? Because personally I have absolutely no idea what all this garbage means. From giallu at gmail.com Fri Apr 6 08:57:40 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 6 Apr 2007 10:57:40 +0200 Subject: [Fedora-packaging] rpm output guidelines In-Reply-To: References: Message-ID: On 4/6/07, Christopher Stone wrote: > Why is my console littered with tons of output when I update > selinux-policy-targeted rpm? I get tons of crap spewed out to my > console. Aren't there any guidelines to prevent packages from doing > this, and if not can we please make some? I think you are right, the package %post scriptlet has to be fixed. Instead of opening a new bug, I suggest you chime in: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226406 so this can be sorted out before the merge From Axel.Thimm at ATrpms.net Fri Apr 6 16:04:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 6 Apr 2007 18:04:56 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras Message-ID: <20070406160456.GB2318@neu.nirvana> Hi, I checked on the percentage of how many packages do use disttags these days. And since I was at it I did some historical reseach to see the tendency (I don't have access to Pre-Extras, so the Extras and Sum slots for FC1 and FC2 are empty). The results are quite interesting: release Fedora Core Fedora Extras Sum 1 2 / 936 <1% 2 0 / 947 0% 3 9 / 970 1% 711 / 1115 64% 720 / 2085 35% 4 12 / 965 1% 1530 / 1786 86% 1542 / 2751 56% 5 36 / 1157 3% 2686 / 2778 97% 2722 / 3935 69% 6 336 / 1154 29% 3008 / 3068 98% 3344 / 4222 79% rawhide 846 / 1218 69% 2833 / 2897 98% 3679 / 4115 89% Some notes: o Fedora Extras has always used more packages w/ disttags than w/o, the tendency up to its last incarnation in FC6 was steadily increasing until it reached 98% and remained at that level. o Fedora Core has adopted disttags very late in comparison to Fedora Extras, but also has the steepest growth - since FC6 every third package has already been disttag'ed, by F7 it's more than two thirds. This is mostly due to the fact that previously the Fedora Core buildsystem would not support setting the disttag macros, while the Fedora Extras buildsystem did so for the very beginning. o In their sum the disttagged packages have also reached the majority since FC4. Conclusions: o The disttag idiom was very successful, even though it is not mandatory it managed to be adopted in over 98% of Fedora Extras and 69% of Fedora Core. o From EPEL's POV, since it is a Fedora Extras rebuild for RHEL the package pool comes from the 98% of disttagged packages. Although RHEL is smaller than Fedora Core and one would assume some packages in EPEL coming from Fedora Core and thus getting at a lower than 98% share, current EPEL shows that almost all packages but some special ones like epel-release use the disttag. o For any other application that would require mandatory disttags like for example disttags of fc7.89, fc7.90 etc for rawhide and test releases this setup is not very far away. Looking at the sum of packages, this could happen by F8 by itself (the sum gains at least 10% each year and there are only 11% left). Suggestions: o watch the tendency and when it really reaches about 100% (e.g. F8) think about what gains mandatory disttags could bring us. If it is worth it fix the remaining few packages to use disttags (note: not all packages make sense to carry one, firmwares or XXX-release packages for example don't really need them) o continue suggesting the use of disttags to new packagers - even though optional it should be the recommended way to package things up. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Apr 6 16:29:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Apr 2007 18:29:36 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070406160456.GB2318@neu.nirvana> References: <20070406160456.GB2318@neu.nirvana> Message-ID: <20070406162936.GA5416@free.fr> On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote: > Hi, > > o continue suggesting the use of disttags to new packagers - even > though optional it should be the recommended way to package things > up. But remember that for data noarch packages, and software noarch packages that don't in stall in versionned interpreter directory disttages are harmfull. I though there was something in the wiki about that but I can't find it. -- Pat From fedora at leemhuis.info Fri Apr 6 17:12:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 19:12:53 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070406162936.GA5416@free.fr> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> Message-ID: <46167F95.5060707@leemhuis.info> Patrice Dumas schrieb: > On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote: >> o continue suggesting the use of disttags to new packagers - even >> though optional it should be the recommended way to package things >> up. > But remember that for data noarch packages, and software noarch packages > that don't in stall in versionned interpreter directory disttages are > harmfull. harmfull maybe is a bit strong word, but you have a point. I also plan to remove disttags from those of my packages that update seldom, as I think it's just utterly confusing if there are packages in FC7 that still have a disttag ".fc6" in it. CU thl From pertusus at free.fr Fri Apr 6 17:17:57 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 6 Apr 2007 19:17:57 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <46167F95.5060707@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> Message-ID: <20070406171757.GB5416@free.fr> On Fri, Apr 06, 2007 at 07:12:53PM +0200, Thorsten Leemhuis wrote: > Patrice Dumas schrieb: > > On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote: > >> o continue suggesting the use of disttags to new packagers - even > >> though optional it should be the recommended way to package things > >> up. > > But remember that for data noarch packages, and software noarch packages > > that don't in stall in versionned interpreter directory disttages are > > harmfull. > > harmfull maybe is a bit strong word, but you have a point. Indeed I shouldn't have used harmfull. But being forced to download and install, say, 30M for no reason should be avoided. -- Pat From orion at cora.nwra.com Fri Apr 6 17:52:12 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 06 Apr 2007 11:52:12 -0600 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <46167F95.5060707@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> Message-ID: <461688CC.70509@cora.nwra.com> Thorsten Leemhuis wrote: > I also plan to remove disttags from those of my packages that update > seldom, as I think it's just utterly confusing if there are packages in > FC7 that still have a disttag ".fc6" in it. I would recommend at least one rebuild of a package just before release though for everything but pure data packages. I've been surprised by what has changed and caused failures. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jkeating at redhat.com Fri Apr 6 18:06:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 14:06:52 -0400 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <461688CC.70509@cora.nwra.com> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> Message-ID: <200704061406.53019.jkeating@redhat.com> On Friday 06 April 2007 13:52:12 Orion Poplawski wrote: > I would recommend at least one rebuild of a package just before release > though for everything but pure data packages. ?I've been surprised by > what has changed and caused failures. Continuous rebuilds are done, just not imported. I think this is great, we get the benefit without the churn. Churning the entire package set without reason is ridiculous and may do more harm than good. See Matt D's core/extras rebuild reports. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Apr 6 18:14:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 20:14:52 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <461688CC.70509@cora.nwra.com> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> Message-ID: <46168E1C.1010209@leemhuis.info> Orion Poplawski schrieb: > Thorsten Leemhuis wrote: >> I also plan to remove disttags from those of my packages that update >> seldom, as I think it's just utterly confusing if there are packages in >> FC7 that still have a disttag ".fc6" in it. > I would recommend at least one rebuild of a package just before release > though for everything but pure data packages. I've been surprised by > what has changed and caused failures. Just before release sounds bad, as that could create new bugs. So before test2 normally (test3 for FC7 as we have a test4) would be be better IMHO. But even better would be to build the package to a your home machine or into a scratch repo where it gets deleted after building (Iand not pushed) -- that way people that live in areas where internet bandwidth is costly are not forced to download a new package on update when nothing changed. CU thl From Axel.Thimm at ATrpms.net Fri Apr 6 18:22:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 6 Apr 2007 20:22:40 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <200704061406.53019.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> <200704061406.53019.jkeating@redhat.com> Message-ID: <20070406182240.GD2318@neu.nirvana> On Fri, Apr 06, 2007 at 02:06:52PM -0400, Jesse Keating wrote: > On Friday 06 April 2007 13:52:12 Orion Poplawski wrote: > > I would recommend at least one rebuild of a package just before release > > though for everything but pure data packages. ?I've been surprised by > > what has changed and caused failures. > > Continuous rebuilds are done, just not imported. I think this is great, we > get the benefit without the churn. Churning the entire package set without > reason is ridiculous and may do more harm than good. See Matt D's > core/extras rebuild reports. But nobody tests them. Only fatal build errors are probed that way. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From orion at cora.nwra.com Fri Apr 6 18:23:42 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 06 Apr 2007 12:23:42 -0600 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <200704061406.53019.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> <200704061406.53019.jkeating@redhat.com> Message-ID: <4616902E.3050703@cora.nwra.com> Jesse Keating wrote: > Continuous rebuilds are done, just not imported. I think this is great, we > get the benefit without the churn. Churning the entire package set without > reason is ridiculous and may do more harm than good. See Matt D's > core/extras rebuild reports. > Had forgotten about that. With those checks in place I guess we are okay. So, are we going to worry about .fc6 packages in FC7? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From Axel.Thimm at ATrpms.net Fri Apr 6 18:28:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 6 Apr 2007 20:28:28 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070406162936.GA5416@free.fr> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> Message-ID: <20070406182828.GE2318@neu.nirvana> On Fri, Apr 06, 2007 at 06:29:36PM +0200, Patrice Dumas wrote: > On Fri, Apr 06, 2007 at 06:04:56PM +0200, Axel Thimm wrote: > > Hi, > > > > o continue suggesting the use of disttags to new packagers - even > > though optional it should be the recommended way to package things > > up. > > But remember that for data noarch packages, and software noarch packages > that don't in stall in versionned interpreter directory disttages are > harmfull. I agree, in general anything that wouldn't change from release to release, for example because it just get's installed w/o any processing onto the filesystem should not carry a disttag but be shared as a single instance. Firmwares and content packages come to mind. In fact if we ever (e.g. at F8 release time) decide on making disttag mandatory, we would have to exclude these packages from carrying a disttag and would have thus a handle of identifying cross-distribution/cross-release packages. > I though there was something in the wiki about that but I can't find it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris.stone at gmail.com Fri Apr 6 18:37:15 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 6 Apr 2007 11:37:15 -0700 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <46167F95.5060707@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> Message-ID: On 4/6/07, Thorsten Leemhuis wrote: > I also plan to remove disttags from those of my packages that update > seldom, as I think it's just utterly confusing if there are packages in > FC7 that still have a disttag ".fc6" in it. huh? How is this even physically possible? /me am confused. From orion at cora.nwra.com Fri Apr 6 19:13:18 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 06 Apr 2007 13:13:18 -0600 Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] Message-ID: <46169BCE.8070802@cora.nwra.com> Some interesting information about the shared library execute bit issue. Why is it that we require the execute bit? I found an old post about it maybe being tied to the kernel protecting overwriting running programs, but no idea if that ever was put it place. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -------------- next part -------------- An embedded message was scrubbed... From: "Alan W. Irwin" Subject: Re: [CMake] cmake does not set execute bit on shared libraries Date: Fri, 06 Apr 2007 10:32:14 -0700 (PDT) Size: 4237 URL: From zing at fastmail.fm Fri Apr 6 18:52:20 2007 From: zing at fastmail.fm (Zing) Date: Fri, 6 Apr 2007 18:52:20 +0000 (UTC) Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras References: <20070406160456.GB2318@neu.nirvana> Message-ID: On Fri, 06 Apr 2007 18:04:56 +0200, Axel Thimm wrote: > Conclusions: > > o The disttag idiom was very successful, even though it is not > mandatory it managed to be adopted in over 98% of Fedora Extras and > 69% of Fedora Core. I'd just like say, I'd have never used disttags if I wasn't forced to. There was some errors I was getting in trying to commit and build some package and the "recommendation" was to just use disttags. That worked so I never really thought about it since then. So for my case, it didn't really offer anything for me that makes it a "success"; just something I had to do to get my packages to continue through the build system. From tcallawa at redhat.com Fri Apr 6 20:38:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 06 Apr 2007 15:38:10 -0500 Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] In-Reply-To: <46169BCE.8070802@cora.nwra.com> References: <46169BCE.8070802@cora.nwra.com> Message-ID: <1175891890.3729.10.camel@localhost.localdomain> On Fri, 2007-04-06 at 13:13 -0600, Orion Poplawski wrote: > Some interesting information about the shared library execute bit issue. > > Why is it that we require the execute bit? I found an old post about it > maybe being tied to the kernel protecting overwriting running programs, > but no idea if that ever was put it place. Roland, Do you know why we only eu-strip libraries if they have the execute bit set? As the cmake folks pointed out, this is the opposite of Debian's policy (never set the libraries executable). ~spot From ville.skytta at iki.fi Fri Apr 6 21:53:46 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 7 Apr 2007 00:53:46 +0300 Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] In-Reply-To: <1175891890.3729.10.camel@localhost.localdomain> References: <46169BCE.8070802@cora.nwra.com> <1175891890.3729.10.camel@localhost.localdomain> Message-ID: <200704070053.46646.ville.skytta@iki.fi> On Friday 06 April 2007, Tom "spot" Callaway wrote: > On Fri, 2007-04-06 at 13:13 -0600, Orion Poplawski wrote: > > Some interesting information about the shared library execute bit issue. > > > > Why is it that we require the execute bit? I'd be very interested in learning this too. It was also briefly discussed in a recent packaging committee meeting, with no real conclusion: http://fedoraproject.org/wiki/Packaging/IRCLog20070306 > Roland, > > Do you know why we only eu-strip libraries if they have the execute bit > set? As the cmake folks pointed out, this is the opposite of Debian's > policy (never set the libraries executable). Just to clarify, you mean /usr/lib/rpm/redhat/brp-strip? BTW, kernel modules get stripped only if they're executable as well at end of %install, that one should be an easy one to rectify even if execute bits for shared libs are useful. Oh, and ldd says "warning: you do not have execution permission for ..." for whatever non-executable is passed to it. Anyone aware of anything else? From jkeating at redhat.com Fri Apr 6 22:17:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 18:17:00 -0400 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora =?iso-8859-1?q?Core=09and?= Extras In-Reply-To: <4616902E.3050703@cora.nwra.com> References: <20070406160456.GB2318@neu.nirvana> <200704061406.53019.jkeating@redhat.com> <4616902E.3050703@cora.nwra.com> Message-ID: <200704061817.04206.jkeating@redhat.com> On Friday 06 April 2007 14:23:42 Orion Poplawski wrote: > So, are we going to worry about .fc6 packages in FC7? No, I don't believe we are. Maybe a FAQ about the fact that our releases inherit from previous releases and some things don't get/need rebuilt. We are efficient in that we only rebuild for technical reasons. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Apr 6 22:19:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 18:19:10 -0400 Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] In-Reply-To: <200704070053.46646.ville.skytta@iki.fi> References: <46169BCE.8070802@cora.nwra.com> <1175891890.3729.10.camel@localhost.localdomain> <200704070053.46646.ville.skytta@iki.fi> Message-ID: <200704061819.10914.jkeating@redhat.com> On Friday 06 April 2007 17:53:46 Ville Skytt? wrote: > Anyone aware of anything else? It's not just the strip part, but if the library isn't marked executable, it isn't processed for requirements, so quite often library requirements can slip through the cracks of rpm's auto req generation. See a recent bug in FC6 where this happened. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Apr 6 22:30:59 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 7 Apr 2007 01:30:59 +0300 Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] In-Reply-To: <200704061819.10914.jkeating@redhat.com> References: <46169BCE.8070802@cora.nwra.com> <200704070053.46646.ville.skytta@iki.fi> <200704061819.10914.jkeating@redhat.com> Message-ID: <200704070131.00275.ville.skytta@iki.fi> On Saturday 07 April 2007, Jesse Keating wrote: > On Friday 06 April 2007 17:53:46 Ville Skytt? wrote: > > Anyone aware of anything else? > > It's not just the strip part, but if the library isn't marked executable, > it isn't processed for requirements, so quite often library requirements > can slip through the cracks of rpm's auto req generation. Oh, indeed, I tested that before posting but the test was faulty; requirements end up missing indeed (but Provides seem to be fine). From roland at redhat.com Fri Apr 6 22:43:55 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 6 Apr 2007 15:43:55 -0700 (PDT) Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] In-Reply-To: Ville Skyttä's message of Saturday, 7 April 2007 00:53:46 +0300 <200704070053.46646.ville.skytta@iki.fi> Message-ID: <20070406224355.899B9180064@magilla.sf.frob.com> > Just to clarify, you mean /usr/lib/rpm/redhat/brp-strip? I think he meant /usr/lib/rpm/find-debuginfo.sh, but brp-strip behaves the same way. I think brp-strip only winds up really doing anything when debuginfo is disabled. > BTW, kernel modules get stripped only if they're executable as well at end > of %install, that one should be an easy one to rectify even if execute bits > for shared libs are useful. Indeed, recognizing them has only the same issues that recognizing nonexecutable DSO files does. From fedora at leemhuis.info Sat Apr 7 12:28:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 07 Apr 2007 14:28:20 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> Message-ID: <46178E64.5000802@leemhuis.info> Christopher Stone schrieb: > On 4/6/07, Thorsten Leemhuis wrote: >> I also plan to remove disttags from those of my packages that update >> seldom, as I think it's just utterly confusing if there are packages in >> FC7 that still have a disttag ".fc6" in it. > > huh? How is this even physically possible? > /me am confused. You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens if a packages was never rebuild during a devel cycle. And that happens quite often: [thl at truhe ~]$ lftp -c "open http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/extras/development/SRPMS/; ls" > tmpfile [thl at truhe ~]$ wc -l tmpfile 2921 tmpfile [thl at truhe ~]$ grep '.fc6' tmpfile | wc -l 982 [thl at truhe ~]$ Those 982 packages are in my opinion good candidates for not using dist. Cu thl From pertusus at free.fr Sat Apr 7 12:41:06 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Apr 2007 14:41:06 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <46178E64.5000802@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> Message-ID: <20070407124106.GA2933@free.fr> On Sat, Apr 07, 2007 at 02:28:20PM +0200, Thorsten Leemhuis wrote: > > Those 982 packages are in my opinion good candidates for not using dist. That's not completly evident. Among those packages there are a lot of arch packages that weren't updated nor rebuilt, yet disttag for those packages are convenient. -- Pat From fedora at leemhuis.info Sat Apr 7 13:00:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 07 Apr 2007 15:00:36 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070407124106.GA2933@free.fr> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> <20070407124106.GA2933@free.fr> Message-ID: <461795F4.6080602@leemhuis.info> Patrice Dumas schrieb: > On Sat, Apr 07, 2007 at 02:28:20PM +0200, Thorsten Leemhuis wrote: >> Those 982 packages are in my opinion good candidates for not using dist. > That's not completly evident. Among those packages there are a lot of > arch packages that weren't updated nor rebuilt, yet disttag for those > packages are convenient. That why I said "candidates" -- it of course depends on the package itself (maybe it was just a slow devel period upstream with no releases) and the maintainer, if he is willing to take care of some things manually that dists automates. CU thl From nicolas.mailhot at laposte.net Sat Apr 7 13:56:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 07 Apr 2007 15:56:32 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <46178E64.5000802@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> Message-ID: <1175954192.6592.1.camel@rousalka.dyndns.org> Le samedi 07 avril 2007 ? 14:28 +0200, Thorsten Leemhuis a ?crit : > You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens > if a packages was never rebuild during a devel cycle. And that happens > quite often: ... > Those 982 packages are in my opinion good candidates for not using dist. /me looks in apache logs, finds repeated PHP warnings and errors, involving (surprise) a core package still bearing the fc6 tag -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Sat Apr 7 14:53:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 7 Apr 2007 16:53:47 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <461795F4.6080602@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> <20070407124106.GA2933@free.fr> <461795F4.6080602@leemhuis.info> Message-ID: <20070407145347.GC15052@neu.nirvana> On Sat, Apr 07, 2007 at 03:00:36PM +0200, Thorsten Leemhuis wrote: > Patrice Dumas schrieb: > > On Sat, Apr 07, 2007 at 02:28:20PM +0200, Thorsten Leemhuis wrote: > >> Those 982 packages are in my opinion good candidates for not using dist. > > That's not completly evident. Among those packages there are a lot of > > arch packages that weren't updated nor rebuilt, yet disttag for those > > packages are convenient. > > That why I said "candidates" -- it of course depends on the package > itself (maybe it was just a slow devel period upstream with no releases) > and the maintainer, if he is willing to take care of some things > manually that dists automates. Anything that may yield different content depending on what release/distro it was built on needs to have a disttag or some other manual package upgrade management function. And even if for some packages the contents did't change between FC6 and F7, they may do so between F7 and F8. Otherwise indeed, the package should not carry a disttag at all, since it will run the same on FC3 to F10 and RHEL3-RHEL6. But that is seldom the case, even noarch packages like perl and python noarch packages live in different folders across releases. The fact that there was no mass-rebuild this time for F7 may or may not have a nasty outcome. Just like exim which was "forgotten" [1] to be rebuilt during FC5's release cycle and would have runtime errors (I think due to a changed pam-devel package). [1] it wasn't forgotten, it was just rebuilt too early and needed another rebuilt. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeremy at hinegardner.org Sun Apr 8 18:47:26 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Sun, 8 Apr 2007 12:47:26 -0600 Subject: [Fedora-packaging] exemptions for .la files in some -devel packages ? Message-ID: <20070408184726.GK643@hinegardner.org> Hi all, I'm doing a couple of Merge Reviews for apr[1] and apr-util[2] and there seems to be an issue over the inclusion of the .la files in the apr-devel and apr-util-devel rpms. According to the Review Guidelines .la files are NOT allowed, but I have been informed via the bugzilla tickets that the .la files in these packages are required and cannot be removed. I do not have enough insight on libtool archives to render a decision here, so from my perspective, it appears that one of two things must happen: 1) There needs to be a clarification in the Review Guidelines regarding .la files that there are rare(?) instances where .la files are required and either list them or bring them up on a case-by-case basis to this list. 2) There is a misunderstanding from the packagers perspective on this issue. I'm initially assuming that the former is the correct approach here and just want to get confirmation from the list, as I'm probably newer than most at this process. enjoy, -jeremy [1] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225253 [2] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225254 -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From chris.stone at gmail.com Sun Apr 8 19:20:22 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 8 Apr 2007 12:20:22 -0700 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <46178E64.5000802@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> Message-ID: On 4/7/07, Thorsten Leemhuis wrote: > Christopher Stone schrieb: > > On 4/6/07, Thorsten Leemhuis wrote: > >> I also plan to remove disttags from those of my packages that update > >> seldom, as I think it's just utterly confusing if there are packages in > >> FC7 that still have a disttag ".fc6" in it. > > > > huh? How is this even physically possible? > > /me am confused. > > You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens > if a packages was never rebuild during a devel cycle. And that happens > quite often: So in other words, when the release team branches devel to F7 they don't do a rebuild on all packages like they should? This seems just a little dangerous to me. All packages should be rebuilt on branches. I am really quite surprised that this is not already done. There are already automatic rebuilding scripts, why not just kick off a shell script? I would think that checking that a package actually builds before a release would be somewhat important... From tcallawa at redhat.com Sun Apr 8 19:37:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 08 Apr 2007 14:37:40 -0500 Subject: [Fedora-packaging] exemptions for .la files in some -devel packages ? In-Reply-To: <20070408184726.GK643@hinegardner.org> References: <20070408184726.GK643@hinegardner.org> Message-ID: <1176061060.3970.7.camel@localhost.localdomain> On Sun, 2007-04-08 at 12:47 -0600, Jeremy Hinegardner wrote: > Hi all, > > I'm doing a couple of Merge Reviews for apr[1] and apr-util[2] and there > seems to be an issue over the inclusion of the .la files in the > apr-devel and apr-util-devel rpms. > > According to the Review Guidelines .la files are NOT allowed, but I have > been informed via the bugzilla tickets that the .la files in these > packages are required and cannot be removed. If the .la files are absolutely necessary, then they can be left in (with a comment describing why). All effort should be made to eliminate them. I know that some of the KDE packages managed to eliminate the need for .la files, perhaps that work would apply to apr-* as well? ~spot From rdieter at math.unl.edu Mon Apr 9 00:56:53 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 08 Apr 2007 19:56:53 -0500 Subject: [Fedora-packaging] exemptions for .la files in some -devel packages ? In-Reply-To: <20070408184726.GK643@hinegardner.org> References: <20070408184726.GK643@hinegardner.org> Message-ID: <46198F55.80803@math.unl.edu> Jeremy Hinegardner wrote: > I'm doing a couple of Merge Reviews for apr[1] and apr-util[2] and there > seems to be an issue over the inclusion of the .la files in the > apr-devel and apr-util-devel rpms. > > According to the Review Guidelines .la files are NOT allowed, but I have > been informed via the bugzilla tickets that the .la files in these > packages are required and cannot be removed. ... > [1] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225253 > [2] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225254 There are always exceptions, though I'll take a closer look myself tomorrow. I would venture that apr/apr-util is fixable, whether that means moving the .la files to -static or omitting altogether. -- Rex From a.badger at gmail.com Mon Apr 9 08:01:21 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Apr 2007 01:01:21 -0700 Subject: [Fedora-packaging] Unadressed bugs as part of reviews Message-ID: <1176105681.9360.49.camel@localhost.localdomain> I saw this set of comments in a merge review and it struck me as a little off: > 5. There are outstanding bugs for [pkg] please address them. This is not relevant to the packaging review process. I see two problems with the above statements: 1) The reviewer is not specifying a specific problem that they consider a blocker for approval of the package. 2) The packager is not acknowledging that potential problems with the runtime of the package are relevant to the review. Perhaps we need to have some statement of reviewers' and packagers' responsibilities at the top of the Guidelines: "It is the reviewer's responsibility to point out specific problems with a package and a packager's responsibility to deal with those issues. The reviewer and packager work together to determine the severity of the issues (whether they block a package or can be worked on after the package is in the repository.) The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. If a reviewer or packager believe their package reveals a flaw in the Guidelines, examples of how the rule is failing should be brought to the attention of the Packaging Committee so they can consider whether the rule has unanticipated consequences and modify it to better fit all situations." [1]_ Let me know what you think of having such a statement in general and this wording in particular. [1]_: http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals -Toshio -------------- 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 fedora at leemhuis.info Mon Apr 9 09:55:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 09 Apr 2007 11:55:43 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> Message-ID: <461A0D9F.7000602@leemhuis.info> Christopher Stone schrieb: > On 4/7/07, Thorsten Leemhuis wrote: >> Christopher Stone schrieb: >>> On 4/6/07, Thorsten Leemhuis wrote: >>>> I also plan to remove disttags from those of my packages that update >>>> seldom, as I think it's just utterly confusing if there are packages in >>>> FC7 that still have a disttag ".fc6" in it. >>> huh? How is this even physically possible? >>> /me am confused. >> You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens >> if a packages was never rebuild during a devel cycle. And that happens >> quite often: > > So in other words, when the release team branches devel to F7 they > don't do a rebuild on all packages like they should? > > This seems just a little dangerous to me. All packages should be > rebuilt on branches. /me is nor sure if Christopher means the devel branch before or after branching for F7 (in this case). > I am really quite surprised that this is not > already done. There are already automatic rebuilding scripts, why not > just kick off a shell script? Because some packagers dislike that? To avoid that users have to download new packages just because they were rebuild? There are probably more reasons that don't come to my mind yet. Anyway, that stuff in packaging in practice. fedora-devel or fedora-maintainers would thus be the better place to discuss this. > I would think that checking that a package actually builds before a > release would be somewhat important... There are Matt's rebuild efforts. They probably should be integrated into the Fedora infrastructure better. E.g. use the normal builders when they are idle to rebuild packages, check them and if the build fails of something is different then send a mail to the maintainer or automatically open a bug. Or something like that. CU thl From rdieter at math.unl.edu Mon Apr 9 13:15:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Apr 2007 08:15:29 -0500 Subject: [Fedora-packaging] exemptions for .la files in some -devel packages ? In-Reply-To: <46198F55.80803@math.unl.edu> References: <20070408184726.GK643@hinegardner.org> <46198F55.80803@math.unl.edu> Message-ID: <461A3C71.2060100@math.unl.edu> Rex Dieter wrote: > Jeremy Hinegardner wrote: > >> I'm doing a couple of Merge Reviews for apr[1] and apr-util[2] and there >> seems to be an issue over the inclusion of the .la files in the >> apr-devel and apr-util-devel rpms. >> >> According to the Review Guidelines .la files are NOT allowed, but I have >> been informed via the bugzilla tickets that the .la files in these >> packages are required and cannot be removed. > ... >> [1] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225253 >> [2] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225254 > > There are always exceptions, though I'll take a closer look myself > tomorrow. I would venture that apr/apr-util is fixable, whether that > means moving the .la files to -static or omitting altogether. Upon further investigation, I'm not convinced (yet) that including .la files here is justified, though I've asked Joe for clarification of his position on that: http://bugzilla.redhat.com/225253#c11 fwiw, I've rebuilt apr/apr-util/subversion/neon with .la files omitted, and haven't discovered any immediate problems. The only hint of his motivation I've found (so far) was in the neon merge review on this same topic: http://bugzilla.redhat.com/226189 "- the .la file is part of the defined interface so will not be dropped. (it's used by third-party apps via "neon-config --la-file" I'm not sure I buy this argument, and I'd argue 3rd party apps should be fixed to not rely on the .la file(s) being present. Opinions? -- Rex From rdieter at math.unl.edu Mon Apr 9 13:19:39 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Apr 2007 08:19:39 -0500 Subject: [Fedora-packaging] Re: Unadressed bugs as part of reviews References: <1176105681.9360.49.camel@localhost.localdomain> Message-ID: Toshio Kuratomi wrote: > I saw this set of comments in a merge review and it struck me as a > little off: > > 5. There are outstanding bugs for [pkg] please address them. > This is not relevant to the packaging review process. As stated, I agree, it's just too vague. What is relevant, however, are reviewers mentioning *specific* current/outstanding issues/bugs that ought to be addressed. -- Rex From rdieter at math.unl.edu Mon Apr 9 15:39:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Apr 2007 10:39:32 -0500 Subject: [Fedora-packaging] Re: cmake does not set execute bit on shared libraries In-Reply-To: <46169BCE.8070802@cora.nwra.com> References: <46169BCE.8070802@cora.nwra.com> Message-ID: <461A5E34.5090405@math.unl.edu> Orion Poplawski wrote: > Some interesting information about the shared library execute bit issue. FYI, I think the patch from http://bugzilla.redhat.com/235673 can address our immediate needs, at least until we hear anything more definitive from upstream. -- Rex From chris.stone at gmail.com Mon Apr 9 16:12:18 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 9 Apr 2007 09:12:18 -0700 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <461A0D9F.7000602@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> <461A0D9F.7000602@leemhuis.info> Message-ID: On 4/9/07, Thorsten Leemhuis wrote: > > Christopher Stone schrieb: > > On 4/7/07, Thorsten Leemhuis wrote: > >> Christopher Stone schrieb: > >>> On 4/6/07, Thorsten Leemhuis wrote: > >>>> I also plan to remove disttags from those of my packages that update > >>>> seldom, as I think it's just utterly confusing if there are packages in > >>>> FC7 that still have a disttag ".fc6" in it. > >>> huh? How is this even physically possible? > >>> /me am confused. > >> You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens > >> if a packages was never rebuild during a devel cycle. And that happens > >> quite often: > > > > So in other words, when the release team branches devel to F7 they > > don't do a rebuild on all packages like they should? > > > > This seems just a little dangerous to me. All packages should be > > rebuilt on branches. > > /me is nor sure if Christopher means the devel branch before or after > branching for F7 (in this case). Well, what makes most sense to me is to branch devel to F7. Then do a rebuild on all the packages in F7. This should be done at the time when you freeze stuff (that is only bug fixes go in). This way package maintainers can put big changes in devel and bug fixes in F7. > > > I am really quite surprised that this is not > > already done. There are already automatic rebuilding scripts, why not > > just kick off a shell script? > > Because some packagers dislike that? To avoid that users have to > download new packages just because they were rebuild? There are probably > more reasons that don't come to my mind yet. Why would you have to download a new package? You arent bumping the release tag or changing the spec file at all. All you are doing is firing off a build of the current package in a new branch. Maintainers have to cvs up -d when new branches take place anyway, so I don't see the issue here. > > Anyway, that stuff in packaging in practice. fedora-devel or > fedora-maintainers would thus be the better place to discuss this. > > > I would think that checking that a package actually builds before a > > release would be somewhat important... > > There are Matt's rebuild efforts. They probably should be integrated > into the Fedora infrastructure better. E.g. use the normal builders when > they are idle to rebuild packages, check them and if the build fails of > something is different then send a mail to the maintainer or > automatically open a bug. Or something like that. Indeed, this would be a good idea. I hate searching through the dozens of packages that don't build to try and find one that belongs to me. Much better to automate the process. Thanks. From tibbs at math.uh.edu Mon Apr 9 16:27:52 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Apr 2007 11:27:52 -0500 Subject: [Fedora-packaging] exemptions for .la files in some -devel packages ? In-Reply-To: <461A3C71.2060100@math.unl.edu> References: <20070408184726.GK643@hinegardner.org> <46198F55.80803@math.unl.edu> <461A3C71.2060100@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> The only hint of his motivation I've found (so far) was in the RD> neon merge review on this same topic: RD> http://bugzilla.redhat.com/226189 "- the .la file is part of the RD> defined interface so will not be dropped. (it's used by RD> third-party apps via "neon-config --la-file" RD> I'm not sure I buy this argument, and I'd argue 3rd party apps RD> should be fixed to not rely on the .la file(s) being present. Well, I bought the argument in that review, perhaps too easily. I didn't feel like yet another argument with a maintainer @redhat.com and I assumed that he actually had examples of things that would break. If someone feels more up to the argument than I, feel free to comment there. - J< From jkeating at redhat.com Mon Apr 9 16:38:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 9 Apr 2007 12:38:30 -0400 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: References: <20070406160456.GB2318@neu.nirvana> <461A0D9F.7000602@leemhuis.info> Message-ID: <200704091238.30883.jkeating@redhat.com> On Monday 09 April 2007 12:12:18 Christopher Stone wrote: > Why would you have to download a new package? ?You arent bumping the > release tag or changing the spec file at all. ? All you are doing is > firing off a build of the current package in a new branch. > Maintainers have to cvs up -d when new branches take place anyway, so > I don't see the issue here. Yet, the disttag WOULD get bumped and everybody would have to download this package as an update just to get the new dist tag. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Apr 9 16:38:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 09 Apr 2007 18:38:11 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> <461A0D9F.7000602@leemhuis.info> Message-ID: <461A6BF3.5000502@leemhuis.info> Christopher Stone schrieb: > On 4/9/07, Thorsten Leemhuis wrote: >> Christopher Stone schrieb: >>> On 4/7/07, Thorsten Leemhuis wrote: >>>> Christopher Stone schrieb: >>>>> On 4/6/07, Thorsten Leemhuis wrote: >>>>>> I also plan to remove disttags from those of my packages that update >>>>>> seldom, as I think it's just utterly confusing if there are packages in >>>>>> FC7 that still have a disttag ".fc6" in it. >>>>> huh? How is this even physically possible? >>>>> /me am confused. >>>> You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens >>>> if a packages was never rebuild during a devel cycle. And that happens >>>> quite often: >>> So in other words, when the release team branches devel to F7 they >>> don't do a rebuild on all packages like they should? >>> >>> This seems just a little dangerous to me. All packages should be >>> rebuilt on branches. >> /me is nor sure if Christopher means the devel branch before or after >> branching for F7 (in this case). > > Well, what makes most sense to me is to branch devel to F7. Then do a > rebuild on all the packages in F7. This should be done at the time > when you freeze stuff (that is only bug fixes go in). This way > package maintainers can put big changes in devel and bug fixes in F7. devel currently gets branched to F7 when F7 is ready (e.g. the rawhide is (nearly) identical to F7 then). Nobody would want to rebuild everything at that point of time ;-) So your idea *with the current branching procedure* is a no go. >>> I am really quite surprised that this is not >>> already done. There are already automatic rebuilding scripts, why not >>> just kick off a shell script? >> Because some packagers dislike that? To avoid that users have to >> download new packages just because they were rebuild? There are probably >> more reasons that don't come to my mind yet. > Why would you have to download a new package? You arent bumping the > release tag or changing the spec file at all. All you are doing is > firing off a build of the current package in a new branch. Example: synaptics-0.14.4-8.fc6 in rawhide and FC-6 now; gets rebuild for F7, so new package is named synaptics-0.14.4-8.fc7. Yum/Anaconda will download and update the new package. > [...] CU thl From chris.stone at gmail.com Mon Apr 9 16:55:37 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 9 Apr 2007 09:55:37 -0700 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <461A6BF3.5000502@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <20070406162936.GA5416@free.fr> <46167F95.5060707@leemhuis.info> <46178E64.5000802@leemhuis.info> <461A0D9F.7000602@leemhuis.info> <461A6BF3.5000502@leemhuis.info> Message-ID: On 4/9/07, Thorsten Leemhuis wrote: > Christopher Stone schrieb: > > On 4/9/07, Thorsten Leemhuis wrote: > >> Christopher Stone schrieb: > >>> On 4/7/07, Thorsten Leemhuis wrote: > >>>> Christopher Stone schrieb: > >>>>> On 4/6/07, Thorsten Leemhuis wrote: > >>>>>> I also plan to remove disttags from those of my packages that update > >>>>>> seldom, as I think it's just utterly confusing if there are packages in > >>>>>> FC7 that still have a disttag ".fc6" in it. > >>>>> huh? How is this even physically possible? > >>>>> /me am confused. > >>>> You mean "Packages in FC7 that have .fc6 as disttag"? Easy: That happens > >>>> if a packages was never rebuild during a devel cycle. And that happens > >>>> quite often: > >>> So in other words, when the release team branches devel to F7 they > >>> don't do a rebuild on all packages like they should? > >>> > >>> This seems just a little dangerous to me. All packages should be > >>> rebuilt on branches. > >> /me is nor sure if Christopher means the devel branch before or after > >> branching for F7 (in this case). > > > > Well, what makes most sense to me is to branch devel to F7. Then do a > > rebuild on all the packages in F7. This should be done at the time > > when you freeze stuff (that is only bug fixes go in). This way > > package maintainers can put big changes in devel and bug fixes in F7. > > devel currently gets branched to F7 when F7 is ready (e.g. the rawhide > is (nearly) identical to F7 then). Nobody would want to rebuild > everything at that point of time ;-) > > So your idea *with the current branching procedure* is a no go. > > >>> I am really quite surprised that this is not > >>> already done. There are already automatic rebuilding scripts, why not > >>> just kick off a shell script? > >> Because some packagers dislike that? To avoid that users have to > >> download new packages just because they were rebuild? There are probably > >> more reasons that don't come to my mind yet. > > Why would you have to download a new package? You arent bumping the > > release tag or changing the spec file at all. All you are doing is > > firing off a build of the current package in a new branch. > > Example: synaptics-0.14.4-8.fc6 in rawhide and FC-6 now; gets rebuild > for F7, so new package is named synaptics-0.14.4-8.fc7. Yum/Anaconda > will download and update the new package. Ah I see. So, what is this yum-presto package I've seen recently and delta rpms? I don't know much about it, but it sounds like a solution to this "problem". From a.badger at gmail.com Mon Apr 9 16:57:48 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 09 Apr 2007 09:57:48 -0700 Subject: [Fedora-packaging] Re: Unadressed bugs as part of reviews In-Reply-To: References: <1176105681.9360.49.camel@localhost.localdomain> Message-ID: <1176137868.9360.56.camel@localhost.localdomain> On Mon, 2007-04-09 at 08:19 -0500, Rex Dieter wrote: > Toshio Kuratomi wrote: > > > I saw this set of comments in a merge review and it struck me as a > > little off: > > > 5. There are outstanding bugs for [pkg] please address them. > > This is not relevant to the packaging review process. > > As stated, I agree, it's just too vague. > > What is relevant, however, are reviewers mentioning *specific* > current/outstanding issues/bugs that ought to be addressed. > Exactly. Do you think my proposal makes it more obvious that this is what we want or less? (Or is it just verbiage that people will skip over because it's not part of a checklist?) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Apr 9 17:07:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 9 Apr 2007 13:07:12 -0400 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: References: <20070406160456.GB2318@neu.nirvana> <461A6BF3.5000502@leemhuis.info> Message-ID: <200704091307.12417.jkeating@redhat.com> On Monday 09 April 2007 12:55:37 Christopher Stone wrote: > Ah I see. ?So, what is this yum-presto package I've seen recently and > delta rpms? ?I don't know much about it, but it sounds like a solution > to this "problem". It lessens the problem but doesn't do anything for the amount of processing time needed to process all these needless updates. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris.stone at gmail.com Mon Apr 9 17:13:25 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 9 Apr 2007 10:13:25 -0700 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <200704091307.12417.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <461A6BF3.5000502@leemhuis.info> <200704091307.12417.jkeating@redhat.com> Message-ID: On 4/9/07, Jesse Keating wrote: > On Monday 09 April 2007 12:55:37 Christopher Stone wrote: > > Ah I see. So, what is this yum-presto package I've seen recently and > > delta rpms? I don't know much about it, but it sounds like a solution > > to this "problem". > > It lessens the problem but doesn't do anything for the amount of processing > time needed to process all these needless updates. Checking to see if a package still builds correctly is more important than a little extra processing time during upgrades. I'm pretty sure people expect full upgrades to take a bit of time. Just my opinoin. From jkeating at redhat.com Mon Apr 9 17:18:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 9 Apr 2007 13:18:19 -0400 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: References: <20070406160456.GB2318@neu.nirvana> <200704091307.12417.jkeating@redhat.com> Message-ID: <200704091318.19922.jkeating@redhat.com> On Monday 09 April 2007 13:13:25 Christopher Stone wrote: > Checking to see if a package still builds correctly is more important > than a little extra processing time during upgrades. ?I'm pretty sure > people expect full upgrades to take a bit of time. > > Just my opinoin. What you fail to realize is that you can accomplish checking to see if things build correctly without making those builds go to everybody in the universe as an update. These things are not tied together. I'm all for continuous rebuild testing, what I'm not for is continuous churning of packages needlessly that users have to consume. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chris.stone at gmail.com Mon Apr 9 17:26:02 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 9 Apr 2007 10:26:02 -0700 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <200704091318.19922.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <200704091307.12417.jkeating@redhat.com> <200704091318.19922.jkeating@redhat.com> Message-ID: On 4/9/07, Jesse Keating wrote: > On Monday 09 April 2007 13:13:25 Christopher Stone wrote: > > Checking to see if a package still builds correctly is more important > > than a little extra processing time during upgrades. I'm pretty sure > > people expect full upgrades to take a bit of time. > > > > Just my opinoin. > > What you fail to realize is that you can accomplish checking to see if things > build correctly without making those builds go to everybody in the universe > as an update. These things are not tied together. > > I'm all for continuous rebuild testing, what I'm not for is continuous > churning of packages needlessly that users have to consume. I realize it, I just think you aren't sacrificing much to update dist tags on a new release, so in my opinion you may as well do a rebuild test on the branch itself as part of the release process. The only semi-official way to upgrade is to download the dvd anyway. And for the people who upgrade via yum, they will have to wait an extra few minutes to download a couple megs of dist tag deltas and headers. Not a very big deal in my opinion. Just an idea, nothing more. Whether or not you choose to implement it for F8 is ofcourse entirely up to the release team. From orion at cora.nwra.com Mon Apr 9 17:30:27 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 09 Apr 2007 11:30:27 -0600 Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] In-Reply-To: <46169BCE.8070802@cora.nwra.com> References: <46169BCE.8070802@cora.nwra.com> Message-ID: <461A7833.2060100@cora.nwra.com> Orion Poplawski wrote: > Some interesting information about the shared library execute bit issue. > > Why is it that we require the execute bit? I found an old post about it > maybe being tied to the kernel protecting overwriting running programs, > but no idea if that ever was put it place. So, any closer to an answer on this question? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From tcallawa at redhat.com Mon Apr 9 18:27:57 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Apr 2007 13:27:57 -0500 Subject: [Fedora-packaging] [Fwd: Re: [CMake] cmake does not set execute bit on shared libraries] In-Reply-To: <461A7833.2060100@cora.nwra.com> References: <46169BCE.8070802@cora.nwra.com> <461A7833.2060100@cora.nwra.com> Message-ID: <1176143277.3970.33.camel@localhost.localdomain> On Mon, 2007-04-09 at 11:30 -0600, Orion Poplawski wrote: > Orion Poplawski wrote: > > Some interesting information about the shared library execute bit issue. > > > > Why is it that we require the execute bit? I found an old post about it > > maybe being tied to the kernel protecting overwriting running programs, > > but no idea if that ever was put it place. > > So, any closer to an answer on this question? The short answer: This is how rpm marks files for tracking requires and stripping debuginfo. Is this the best way to do it? Probably not. Seems like a good target for improvement in upstream rpm. I'm sure they'd love some patches. ~spot From nicolas.mailhot at laposte.net Mon Apr 9 18:49:48 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 09 Apr 2007 20:49:48 +0200 Subject: [Fedora-packaging] Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <200704091318.19922.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <200704091307.12417.jkeating@redhat.com> <200704091318.19922.jkeating@redhat.com> Message-ID: <1176144588.21151.1.camel@rousalka.dyndns.org> Le lundi 09 avril 2007 ? 13:18 -0400, Jesse Keating a ?crit : > On Monday 09 April 2007 13:13:25 Christopher Stone wrote: > > Checking to see if a package still builds correctly is more important > > than a little extra processing time during upgrades. I'm pretty sure > > people expect full upgrades to take a bit of time. > > > > Just my opinoin. > > What you fail to realize is that you can accomplish checking to see if things > build correctly without making those builds go to everybody in the universe > as an update. These things are not tied together. But you can't accomplish checking the maintainer did check the package builds and works with the rest of a release if you allow old release packages Sorry, but "it builds" is not a good check. Especially if no human ever runs the result -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rdieter at math.unl.edu Mon Apr 9 20:39:09 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 09 Apr 2007 15:39:09 -0500 Subject: [Fedora-packaging] Re: Re: Unadressed bugs as part of reviews References: <1176105681.9360.49.camel@localhost.localdomain> <1176137868.9360.56.camel@localhost.localdomain> Message-ID: Toshio Kuratomi wrote: > Exactly. Do you think my proposal makes it more obvious that this is > what we want or less? I like your draft, it's absolute truth and common-sense, +1 I'm surprised similar text wasn't in the guidelines already. -- Rex From Axel.Thimm at ATrpms.net Mon Apr 9 20:57:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 9 Apr 2007 22:57:18 +0200 Subject: [Fedora-packaging] Full repo rebuilds (was: Statistics on usage of disttags in Fedora Core and Extras) In-Reply-To: <1176144588.21151.1.camel@rousalka.dyndns.org> References: <20070406160456.GB2318@neu.nirvana> <200704091307.12417.jkeating@redhat.com> <200704091318.19922.jkeating@redhat.com> <1176144588.21151.1.camel@rousalka.dyndns.org> Message-ID: <20070409205718.GA4845@neu.nirvana> On Mon, Apr 09, 2007 at 08:49:48PM +0200, Nicolas Mailhot wrote: > Le lundi 09 avril 2007 ? 13:18 -0400, Jesse Keating a ?crit : > > On Monday 09 April 2007 13:13:25 Christopher Stone wrote: > > > Checking to see if a package still builds correctly is more important > > > than a little extra processing time during upgrades. I'm pretty sure > > > people expect full upgrades to take a bit of time. > > > > > > Just my opinoin. > > > > What you fail to realize is that you can accomplish checking to see if things > > build correctly without making those builds go to everybody in the universe > > as an update. These things are not tied together. > > But you can't accomplish checking the maintainer did check the package > builds and works with the rest of a release if you allow old release > packages > > Sorry, but "it builds" is not a good check. Especially if no human ever > runs the result I agree with Nicolas, at least one test release should be used to rebuild everything in rawhide and have thus the result tested. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From petersen at redhat.com Tue Apr 10 02:24:29 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 10 Apr 2007 12:24:29 +1000 Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: <46130BD7.3070708@redhat.com> References: <46130BD7.3070708@redhat.com> Message-ID: <461AF55D.7090704@redhat.com> Hi, The Fonts scriptlet on Packaging/ScriptletSnippets should list the following requires too: Requires(post): fontconfig Requires(postun): fontconfig Jens From fedora at leemhuis.info Tue Apr 10 04:53:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 10 Apr 2007 06:53:05 +0200 Subject: [Fedora-packaging] Full repo rebuilds In-Reply-To: <20070409205718.GA4845@neu.nirvana> References: <20070406160456.GB2318@neu.nirvana> <200704091307.12417.jkeating@redhat.com> <200704091318.19922.jkeating@redhat.com> <1176144588.21151.1.camel@rousalka.dyndns.org> <20070409205718.GA4845@neu.nirvana> Message-ID: <461B1831.5000902@leemhuis.info> On 09.04.2007 22:57, Axel Thimm wrote: > On Mon, Apr 09, 2007 at 08:49:48PM +0200, Nicolas Mailhot wrote: >> Le lundi 09 avril 2007 ? 13:18 -0400, Jesse Keating a ?crit : >>> On Monday 09 April 2007 13:13:25 Christopher Stone wrote: >>>> Checking to see if a package still builds correctly is more important >>>> than a little extra processing time during upgrades. I'm pretty sure >>>> people expect full upgrades to take a bit of time. >>>> Just my opinoin. >>> What you fail to realize is that you can accomplish checking to see if things >>> build correctly without making those builds go to everybody in the universe >>> as an update. These things are not tied together. >> But you can't accomplish checking the maintainer did check the package >> builds and works with the rest of a release if you allow old release >> packages >> Sorry, but "it builds" is not a good check. Especially if no human ever >> runs the result > I agree with Nicolas, at least one test release should be used to > rebuild everything in rawhide and have thus the result tested. I kind of agree with you two that testing the freshly build packages would be best. But *I* think not rebuilding everything when there is no need to is more important, because - the existing packages are out in the wild and we know that those work well - we seem to have users in countries were internet bandwidth seems to be costly and unreliable. We make it a lot easier for those people if we don't force them to download and update new packages that were rebuild without real improvements The compromise that IMHO should makes both sides happy: we have mass-rebuilds quite often anyway (probably every two or three releases due to toolchain changes; e.g. once a year). We rebuild and test everything then in any case anyway and that IMHO should be sufficient -- so lets skip releases like F7. CU thl From nicolas.mailhot at laposte.net Tue Apr 10 05:58:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Apr 2007 07:58:27 +0200 Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: <461AF55D.7090704@redhat.com> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> Message-ID: <1176184707.25025.0.camel@rousalka.dyndns.org> Le mardi 10 avril 2007 ? 12:24 +1000, Jens Petersen a ?crit : > The Fonts scriptlet on Packaging/ScriptletSnippets should list the > following requires too: > > Requires(post): fontconfig > Requires(postun): fontconfig Nope. Their whole point is not to add a fontconfig dep to font packages -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Tue Apr 10 06:55:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 08:55:47 +0200 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <461B1831.5000902@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <200704091307.12417.jkeating@redhat.com> <200704091318.19922.jkeating@redhat.com> <1176144588.21151.1.camel@rousalka.dyndns.org> <20070409205718.GA4845@neu.nirvana> <461B1831.5000902@leemhuis.info> Message-ID: <20070410065547.GA12110@neu.nirvana> On Tue, Apr 10, 2007 at 06:53:05AM +0200, Thorsten Leemhuis wrote: > On 09.04.2007 22:57, Axel Thimm wrote: > > On Mon, Apr 09, 2007 at 08:49:48PM +0200, Nicolas Mailhot wrote: > >> Le lundi 09 avril 2007 ? 13:18 -0400, Jesse Keating a ?crit : > >>> On Monday 09 April 2007 13:13:25 Christopher Stone wrote: > >>>> Checking to see if a package still builds correctly is more important > >>>> than a little extra processing time during upgrades. I'm pretty sure > >>>> people expect full upgrades to take a bit of time. > >>>> Just my opinoin. > >>> What you fail to realize is that you can accomplish checking to see if things > >>> build correctly without making those builds go to everybody in the universe > >>> as an update. These things are not tied together. > >> But you can't accomplish checking the maintainer did check the package > >> builds and works with the rest of a release if you allow old release > >> packages > >> Sorry, but "it builds" is not a good check. Especially if no human ever > >> runs the result > > I agree with Nicolas, at least one test release should be used to > > rebuild everything in rawhide and have thus the result tested. > > I kind of agree with you two that testing the freshly build packages > would be best. But *I* think not rebuilding everything when there is no > need to is more important, because > > - the existing packages are out in the wild and we know that those work well I've seen this argument twice now and I think it's both faulty and dangerous: How can you consider packages to be "stable" when there is fear that simply rebuilding them in a different environment will break them, especially when this environment is the one the release is defined with? These are exactly the fragile packages we're after and don't want to wave into the release w/o a fix. Currently we're running into the release with closed eyes. > - we seem to have users in countries were internet bandwidth seems to be > costly and unreliable. We make it a lot easier for those people if we > don't force them to download and update new packages that were rebuild > without real improvements Check out what the real space consumers are, openoffice, glibc and kernels - these always get rebuilt per release. The next rows with libstdc++, kdebase or the Mozilla projects do so as well. As a matter of fact if counted in size almost everything on the CD/DVD spins in the test releases has been rebuilt. So there is no real win here. > The compromise that IMHO should makes both sides happy: we have > mass-rebuilds quite often anyway (probably every two or three releases > due to toolchain changes; e.g. once a year). No, that's not the truth, we had them for every release until now, only F7 got skipped. Check the repo if you can't remember. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Apr 10 12:48:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Apr 2007 08:48:44 -0400 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <20070410065547.GA12110@neu.nirvana> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> Message-ID: <200704100848.44825.jkeating@redhat.com> On Tuesday 10 April 2007 02:55:47 Axel Thimm wrote: > No, that's not the truth, we had them for every release until now, > only F7 got skipped. Check the repo if you can't remember. We haven't on core side. We've done targetted rebuilds of things for specific changes, not every single package. Many noarch packages were not rebuilt for a period of time. With FC6 we rebuilt every package that hadn't yet been built by our new buildsystem, as well as any compiled package that wasn't compiled with the new gcc. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Apr 10 13:05:26 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 10 Apr 2007 09:05:26 -0400 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <200704100848.44825.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> <200704100848.44825.jkeating@redhat.com> Message-ID: <20070410130526.GA2655@jadzia.bu.edu> On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote: > > No, that's not the truth, we had them for every release until now, > > only F7 got skipped. Check the repo if you can't remember. > We haven't on core side. We've done targetted rebuilds of things for specific > changes, not every single package. Many noarch packages were not rebuilt for Yes, this is certainly true, because I've often encountered packages that don't actually rebuild anymore, or worse, rebuild, but act entirely differently. The latter is particularly what I want to avoid. I think we should force-rebuild all packages somewhere in the middle of the development cycle. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mclasen at redhat.com Tue Apr 10 13:12:03 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 10 Apr 2007 15:12:03 +0200 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <20070410130526.GA2655@jadzia.bu.edu> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> <200704100848.44825.jkeating@redhat.com> <20070410130526.GA2655@jadzia.bu.edu> Message-ID: <1176210723.24788.2.camel@localhost.localdomain> On Tue, 2007-04-10 at 09:05 -0400, Matthew Miller wrote: > On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote: > > > No, that's not the truth, we had them for every release until now, > > > only F7 got skipped. Check the repo if you can't remember. > > We haven't on core side. We've done targetted rebuilds of things for specific > > changes, not every single package. Many noarch packages were not rebuilt for > > Yes, this is certainly true, because I've often encountered packages that > don't actually rebuild anymore, or worse, rebuild, but act entirely > differently. The latter is particularly what I want to avoid. I think we > should force-rebuild all packages somewhere in the middle of the development > cycle. There is no guarantee that a rebuild in the middle of the development cycle magically makes the packages rebuildable all the way through the final release. From jkeating at redhat.com Tue Apr 10 13:10:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Apr 2007 09:10:39 -0400 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <1176210723.24788.2.camel@localhost.localdomain> References: <20070406160456.GB2318@neu.nirvana> <20070410130526.GA2655@jadzia.bu.edu> <1176210723.24788.2.camel@localhost.localdomain> Message-ID: <200704100910.42724.jkeating@redhat.com> On Tuesday 10 April 2007 09:12:03 Matthias Clasen wrote: > > Yes, this is certainly true, because I've often encountered packages that > > don't actually rebuild anymore, or worse, rebuild, but act entirely > > differently. The latter is particularly what I want to avoid. I think we > > should force-rebuild all packages somewhere in the middle of the > > development cycle. > > There is no guarantee that a rebuild in the middle of the development > cycle magically makes the packages rebuildable all the way through the > final release. Exactly. It's a false sense of security. Actually looking at the continuous rebuild reports and diffing the package sets or maybe even doing some automated testing with them is the only way to know. And hey, automated testing of package functionality is a good thing, whether done at an automatic throwaway rebuild time or done when a change is introduced into the live package set. Just rebuilding everything at an arbitrary time and hoping for the best is not a solution. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 10 13:33:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 15:33:29 +0200 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <200704100848.44825.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> <200704100848.44825.jkeating@redhat.com> Message-ID: <20070410133329.GC19101@neu.nirvana> On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote: > On Tuesday 10 April 2007 02:55:47 Axel Thimm wrote: > > No, that's not the truth, we had them for every release until now, > > only F7 got skipped. Check the repo if you can't remember. > > We haven't on core side. It depends on what you call a full rebuild. The core side has always rebuilt >= 95% of all packages, most release much more than 99%. I would call that very close to a full rebuild. Here are the numbers of the amount of Core packages rebuilt per release. FC1 gets 100% because I don't have the RHL9 packages handy, but anyway (for > 99% I added as many digits as neccessary to show what wasn't rebuilt): 1 100% 2 99.7% 3 100% 4 96.6% 5 99.991% 6 95% 7 80% So as you see, up to F7 Core had really been effectively rebuilt on each release with FC4 and FC5 being the most "sloppy" ones leaving 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild rate. This *is* a new release model. Just looking at what hasn't been requilt: Some packages like bitstream-fonts really don't deserve a rebuild (they also don't deserve a disttag FWIW), but others like bridge-utils that depend on kernel-headers at build time possibly do, and now we're running with bridge-utils built against 2.6.18. Instead of checking each package whether it should be rebuilt or not, it is easier, faster and correcter to do a full rebuild at release freezing time in the development cycle. > We've done targetted rebuilds of things for specific changes, not > every single package. Many noarch packages were not rebuilt for a > period of time. With FC6 we rebuilt every package that hadn't yet > been built by our new buildsystem, as well as any compiled package > that wasn't compiled with the new gcc. Check the repos, you'll find the same numbers I wrote above. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Apr 10 14:41:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Apr 2007 10:41:07 -0400 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <20070410133329.GC19101@neu.nirvana> References: <20070406160456.GB2318@neu.nirvana> <200704100848.44825.jkeating@redhat.com> <20070410133329.GC19101@neu.nirvana> Message-ID: <200704101041.07696.jkeating@redhat.com> On Tuesday 10 April 2007 09:33:29 Axel Thimm wrote: > 1 100% > 2 99.7% > 3 100% > 4 96.6% > 5 99.991% > 6 95% > 7 80% > > So as you see, up to F7 Core had really been effectively rebuilt on > each release with FC4 and FC5 being the most "sloppy" ones leaving > 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild > rate. This *is* a new release model. What I'm saying is that these numbers often happen naturally instead of forced by a full rebuild. _That_ is the model that hasn't changed. The ONLY time we've done a forced rebuild is for technical reasons and NOT for arbitrary reasons like "hrm, this is test2, maybe we should rebuild everything just for the hell of it" or "there is a lot of disttags that haven't been updated, lets do rebuilds to reset them, that sounds like a good idea...". Rebuilding for technical reasons is fine, relying upon throwaway rebuilds to find said technical reasons is strongly encouraged. Picking arbitrary points to forcefully rebuild everything is not. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Apr 10 14:41:53 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 10 Apr 2007 10:41:53 -0400 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <20070410133329.GC19101@neu.nirvana> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> <200704100848.44825.jkeating@redhat.com> <20070410133329.GC19101@neu.nirvana> Message-ID: <1176216113.3025.6.camel@aglarond.local> On Tue, 2007-04-10 at 15:33 +0200, Axel Thimm wrote: > Just looking at what hasn't been requilt: Some packages like > bitstream-fonts really don't deserve a rebuild (they also don't > deserve a disttag FWIW), but others like bridge-utils that depend on > kernel-headers at build time possibly do, and now we're running with > bridge-utils built against 2.6.18. But see, just rebuilding bridge-utils isn't going to be enough to get any new kernel functionality[1]... you also going to want to get the new release of bridge-utils. And go through any bugs filed. Automated rebuilds tend to hide things like this, which actually lead to more problems down the line Jeremy [1] I don't know if there actually _is_ any in this case, but there is a new bridge-utils upstream release from a quick look at the website. From Axel.Thimm at ATrpms.net Tue Apr 10 14:14:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 16:14:07 +0200 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <20070410130526.GA2655@jadzia.bu.edu> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> <200704100848.44825.jkeating@redhat.com> <20070410130526.GA2655@jadzia.bu.edu> Message-ID: <20070410141407.GD19101@neu.nirvana> On Tue, Apr 10, 2007 at 09:05:26AM -0400, Matthew Miller wrote: > On Tue, Apr 10, 2007 at 08:48:44AM -0400, Jesse Keating wrote: > > > No, that's not the truth, we had them for every release until now, > > > only F7 got skipped. Check the repo if you can't remember. > > We haven't on core side. We've done targetted rebuilds of things for specific > > changes, not every single package. Many noarch packages were not rebuilt for > > Yes, this is certainly true, because I've often encountered packages that > don't actually rebuild anymore, or worse, rebuild, but act entirely > differently. The latter is particularly what I want to avoid. I think we > should force-rebuild all packages somewhere in the middle of the development > cycle. Well, not in the middle, but after the feature freeze. That way anything that blows up wither at build or run time gets fixed while the freeze ensures API/ABI stability (w/ exceptions, of course, but these get handled specially anyway) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 10 15:00:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 17:00:23 +0200 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <1176216113.3025.6.camel@aglarond.local> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> <200704100848.44825.jkeating@redhat.com> <20070410133329.GC19101@neu.nirvana> <1176216113.3025.6.camel@aglarond.local> Message-ID: <20070410150023.GG19101@neu.nirvana> On Tue, Apr 10, 2007 at 10:41:53AM -0400, Jeremy Katz wrote: > On Tue, 2007-04-10 at 15:33 +0200, Axel Thimm wrote: > > Just looking at what hasn't been requilt: Some packages like > > bitstream-fonts really don't deserve a rebuild (they also don't > > deserve a disttag FWIW), but others like bridge-utils that depend on > > kernel-headers at build time possibly do, and now we're running with > > bridge-utils built against 2.6.18. > > But see, just rebuilding bridge-utils isn't going to be enough to get > any new kernel functionality[1]... you also going to want to get the new > release of bridge-utils. And go through any bugs filed. I'm not after *new* functionality, I'm afraid bridge-utils build on possibly deprecated functionality. Maybe bridge-utils requires some love, maybe not, we won't know until someone either review the case or does a rebuild. > Automated rebuilds tend to hide things like this, which actually > lead to more problems down the line > > Jeremy > > [1] I don't know if there actually _is_ any in this case, but there is a > new bridge-utils upstream release from a quick look at the website. That was just an example, I only looked `till the letter "b" and found bitstream and bridge-utils as two opposite examples (one not worth of rebuilds, one the probably is). The point I want to make is that it is easier to do the rebuild and see if something breaks while building and/or running it, than to let it degrade in time and be bitten by it when you least expect it. I don't think automated rebuild would hide any issues, in fact on the contrary, they would expose any issues in our faces, *IFF* the get committed into rawhide proper. That's why I think that the test release tagged "frozen" should be a complete rebuild. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Apr 10 15:12:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Apr 2007 11:12:34 -0400 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <20070410150023.GG19101@neu.nirvana> References: <20070406160456.GB2318@neu.nirvana> <1176216113.3025.6.camel@aglarond.local> <20070410150023.GG19101@neu.nirvana> Message-ID: <200704101112.35069.jkeating@redhat.com> On Tuesday 10 April 2007 11:00:23 Axel Thimm wrote: > That's why I think that the test release tagged "frozen" should be a > complete rebuild. Which would mean starting our QA all over again and throwing out any results up to date. Wrong answer. And this conversation really belongs elsewhere, it isn't a packaging issue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 10 15:22:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 17:22:46 +0200 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <200704101041.07696.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <200704100848.44825.jkeating@redhat.com> <20070410133329.GC19101@neu.nirvana> <200704101041.07696.jkeating@redhat.com> Message-ID: <20070410152246.GH19101@neu.nirvana> On Tue, Apr 10, 2007 at 10:41:07AM -0400, Jesse Keating wrote: > On Tuesday 10 April 2007 09:33:29 Axel Thimm wrote: > > 1 100% > > 2 99.7% > > 3 100% > > 4 96.6% > > 5 99.991% > > 6 95% > > 7 80% > > > > So as you see, up to F7 Core had really been effectively rebuilt on > > each release with FC4 and FC5 being the most "sloppy" ones leaving > > 3.4% and 5% resp. not rebuilt. With F7 Core drops down to 80% rebuild > > rate. This *is* a new release model. > > What I'm saying is that these numbers often happen naturally instead of forced > by a full rebuild. _That_ is the model that hasn't changed. OK, still the packages were all more or less rebuilt, and sometimes the packagers comment this as a simple rebuild for the upcoming release. Which means that while there was no mass-rebuild, many packagers in RH decided to do so on their own when the time came. For F7 the policy obviously changed, otherwise there wouldn't be a sudden drop from 95-100% to 80%. > The ONLY time we've done a forced rebuild is for technical reasons > and NOT for arbitrary reasons like "hrm, this is test2, maybe we > should rebuild everything just for the hell of it" or "there is a > lot of disttags that haven't been updated, lets do rebuilds to reset > them, that sounds like a good idea...". Forget about the disttags, the discussion started about them, but this is not about cosmetics. They only indicate the problem which is that some packages have not been rebuilt. I'm personally against rebuilding just for the fun of nice disttags. But I'm all for rebuilding where it makes a technical difference. Some userland utils depend on kernel-headers, that has changed and in doubt all such dependent packages would require rebuilds or a review. Furthermore glibc has changed in various places among other some sys/personality stuff and kernel 2.4->2.6 bits. Any package that required 2.4 compatibility in this area is now busted (don't remember whether it was sys/personality or something else, check the diff). And who's going to check which packages where using these glibc headers to enforce a per-package rebuild? And this is just the surface scratched. If someone invests more time, he will come up with more dependencies that may now be broken or not, and finding that out takes more developers' time than a simple rebuild-all-and-test-the-outcome model. > Rebuilding for technical reasons is fine, relying upon throwaway > rebuilds to find said technical reasons is strongly encouraged. Ask yourself why they are being thrown away. If there really is no technical reason to rebuild a package, then the rebuilt package can't be broken or less stable that the "old" one. By throwing them away you never have the chance to actually have them tested by a wider audience (or any audience at all). Placing the rebuilds into rawhide instead will really show whether the rebuild was worth it or not, e.g. when things start to break, and you get a change in fixing them. Now we will only get that chance when a package is rebuilt for other reasons post-release, e.g. while adding a security fix. And imagine the confusion of the packager that only changed one line in foo-1.2-3.fc6, successfully rebuilt it to foo-1.2-4.fc7, and the package does not run. Because that scenarion will happen, Matt checks for build errors, so the build will succeed, but the more intricate runtime bugs will only surface when you have the least time to deal with them. And the horror scenario is that since it was a one-liner fix it will get less testing and make it into updates-released being half-broken giving Fedora negative publicity. In short: It's better to have these packages break and fix them during the development/testing cycle than during maintenance. > Picking arbitrary points to forcefully rebuild everything is not. Not an arbitrary point, but at "freeze time" (personally I would rebuild for each test release, but rebuilding once at freeze time would be enough). And again: This has nothing to do with rectifying disttags and cosmetics in the package name, they are for now just an easy metric to see what was rebuilt, and when. And if we'd decide to go for full rebuilds, disttags would be a tool to get 98% done w/o a sweat. But still they are not the problem, they might become the solution instead. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Apr 10 15:40:25 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 10 Apr 2007 11:40:25 -0400 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <1176210723.24788.2.camel@localhost.localdomain> References: <20070406160456.GB2318@neu.nirvana> <461B1831.5000902@leemhuis.info> <20070410065547.GA12110@neu.nirvana> <200704100848.44825.jkeating@redhat.com> <20070410130526.GA2655@jadzia.bu.edu> <1176210723.24788.2.camel@localhost.localdomain> Message-ID: <20070410154025.GA15455@jadzia.bu.edu> On Tue, Apr 10, 2007 at 03:12:03PM +0200, Matthias Clasen wrote: > > Yes, this is certainly true, because I've often encountered packages > > that don't actually rebuild anymore, or worse, rebuild, but act entirely > > differently. The latter is particularly what I want to avoid. I think we > > should force-rebuild all packages somewhere in the middle of the > > development cycle. > There is no guarantee that a rebuild in the middle of the development > cycle magically makes the packages rebuildable all the way through the > final release. That's true. It'll certainly *help*, though. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Tue Apr 10 17:41:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Apr 2007 12:41:48 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change Message-ID: <1176226908.3970.85.camel@localhost.localdomain> Since some of the folks on the Committee have trouble attending our weekly meetings at 1700 UTC, I propose that we move it up an hour to 1600 UTC. FPC members, please vote. I'd like this to be unanimous. :) ~spot From rdieter at math.unl.edu Tue Apr 10 17:46:43 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Apr 2007 12:46:43 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176226908.3970.85.camel@localhost.localdomain> References: <1176226908.3970.85.camel@localhost.localdomain> Message-ID: <461BCD83.4090408@math.unl.edu> Tom "spot" Callaway wrote: > Since some of the folks on the Committee have trouble attending our > weekly meetings at 1700 UTC, I propose that we move it up an hour to > 1600 UTC. > > FPC members, please vote. I'd like this to be unanimous. :) +1 -- Rex From jkeating at redhat.com Tue Apr 10 17:50:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Apr 2007 13:50:13 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176226908.3970.85.camel@localhost.localdomain> References: <1176226908.3970.85.camel@localhost.localdomain> Message-ID: <200704101350.13311.jkeating@redhat.com> On Tuesday 10 April 2007 13:41:48 Tom "spot" Callaway wrote: > Since some of the folks on the Committee have trouble attending our > weekly meetings at 1700 UTC, I propose that we move it up an hour to > 1600 UTC. > > FPC members, please vote. I'd like this to be unanimous. :) -1, that puts it back into my lunch hour :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Apr 10 18:27:06 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Apr 2007 13:27:06 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <200704101350.13311.jkeating@redhat.com> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> Message-ID: <1176229627.3970.88.camel@localhost.localdomain> On Tue, 2007-04-10 at 13:50 -0400, Jesse Keating wrote: > On Tuesday 10 April 2007 13:41:48 Tom "spot" Callaway wrote: > > Since some of the folks on the Committee have trouble attending our > > weekly meetings at 1700 UTC, I propose that we move it up an hour to > > 1600 UTC. > > > > FPC members, please vote. I'd like this to be unanimous. :) > > -1, that puts it back into my lunch hour :/ Well, we're losing folks now because of being during dinner in Europe. Any chance you can do an earlier or later lunch on Tuesdays? ~spot From jkeating at redhat.com Tue Apr 10 19:14:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Apr 2007 15:14:23 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176229627.3970.88.camel@localhost.localdomain> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> <1176229627.3970.88.camel@localhost.localdomain> Message-ID: <200704101514.23982.jkeating@redhat.com> On Tuesday 10 April 2007 14:27:06 Tom "spot" Callaway wrote: > > -1, that puts it back into my lunch hour :/ > > Well, we're losing folks now because of being during dinner in Europe. > Any chance you can do an earlier or later lunch on Tuesdays? Theoretically. What if we moved it two hours earlier or an hour later? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 10 19:23:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 21:23:17 +0200 Subject: [Fedora-packaging] Re: Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176226908.3970.85.camel@localhost.localdomain> References: <1176226908.3970.85.camel@localhost.localdomain> Message-ID: <20070410192317.GC1202@neu.nirvana> On Tue, Apr 10, 2007 at 12:41:48PM -0500, Tom spot Callaway wrote: > Since some of the folks on the Committee have trouble attending our > weekly meetings Sorry, I couldn't make it today and didn't know in advance either, so could notify anyone. :/ > at 1700 UTC, I propose that we move it up an hour to 1600 UTC. > > FPC members, please vote. I'd like this to be unanimous. :) I'm fine with either timeslot. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Tue Apr 10 19:29:45 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 10 Apr 2007 22:29:45 +0300 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <200704101514.23982.jkeating@redhat.com> References: <1176226908.3970.85.camel@localhost.localdomain> <1176229627.3970.88.camel@localhost.localdomain> <200704101514.23982.jkeating@redhat.com> Message-ID: <200704102229.45293.ville.skytta@iki.fi> On Tuesday 10 April 2007, Jesse Keating wrote: > On Tuesday 10 April 2007 14:27:06 Tom "spot" Callaway wrote: > > > -1, that puts it back into my lunch hour :/ > > > > Well, we're losing folks now because of being during dinner in Europe. > > Any chance you can do an earlier or later lunch on Tuesdays? > > Theoretically. What if we moved it two hours earlier or an hour later? Two hours earlier wouldn't work for me outside DST. One hour later would be ok. From tibbs at math.uh.edu Tue Apr 10 19:53:58 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 10 Apr 2007 14:53:58 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <200704101514.23982.jkeating@redhat.com> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> <1176229627.3970.88.camel@localhost.localdomain> <200704101514.23982.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> What if we moved it two hours earlier or an hour later? I can go as early as 13:00UTC or as late as 19:00UTC. - J< From rdieter at math.unl.edu Tue Apr 10 19:58:18 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Apr 2007 14:58:18 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <200704101514.23982.jkeating@redhat.com> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> <1176229627.3970.88.camel@localhost.localdomain> <200704101514.23982.jkeating@redhat.com> Message-ID: <461BEC5A.4010509@math.unl.edu> Jesse Keating wrote: > On Tuesday 10 April 2007 14:27:06 Tom "spot" Callaway wrote: >>> -1, that puts it back into my lunch hour :/ >> Well, we're losing folks now because of being during dinner in Europe. >> Any chance you can do an earlier or later lunch on Tuesdays? > > Theoretically. What if we moved it two hours earlier or an hour later? I'm flexible, either way is ok with me. -- Rex From Axel.Thimm at ATrpms.net Tue Apr 10 20:04:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 22:04:49 +0200 Subject: [Fedora-packaging] Re: Full repo rebuilds In-Reply-To: <200704101112.35069.jkeating@redhat.com> References: <20070406160456.GB2318@neu.nirvana> <1176216113.3025.6.camel@aglarond.local> <20070410150023.GG19101@neu.nirvana> <200704101112.35069.jkeating@redhat.com> Message-ID: <20070410200449.GI1202@neu.nirvana> On Tue, Apr 10, 2007 at 11:12:34AM -0400, Jesse Keating wrote: > On Tuesday 10 April 2007 11:00:23 Axel Thimm wrote: > > That's why I think that the test release tagged "frozen" should be a > > complete rebuild. > > Which would mean starting our QA all over again and throwing out any results > up to date. Wrong answer. Well, FWIW it wasn't the wrong answer for so many releases, and as outlined previously you're pushing the hard bits from the development cycle to the maintenance one. Let's hope we're lucky. > And this conversation really belongs elsewhere, it isn't a packaging > issue. I agree, but it wasn't me who turned this into a rebuild thread. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue Apr 10 20:08:20 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 13:08:20 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <200704101514.23982.jkeating@redhat.com> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> <1176229627.3970.88.camel@localhost.localdomain> <200704101514.23982.jkeating@redhat.com> Message-ID: <1176235700.30783.57.camel@localhost.localdomain> On Tue, 2007-04-10 at 15:14 -0400, Jesse Keating wrote: > On Tuesday 10 April 2007 14:27:06 Tom "spot" Callaway wrote: > > > -1, that puts it back into my lunch hour :/ > > > > Well, we're losing folks now because of being during dinner in Europe. > > Any chance you can do an earlier or later lunch on Tuesdays? > > Theoretically. What if we moved it two hours earlier or an hour later? > Two hours earlier is 8AM on the West Coast. I'm not commuting right now so that ought to be doable for me at the moment. An hour later is fine. -Toshio -------------- 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 ville.skytta at iki.fi Tue Apr 10 20:51:22 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 10 Apr 2007 23:51:22 +0300 Subject: [Fedora-packaging] Re: Fedora Packaging Committee Meeting Time Change In-Reply-To: <20070410192317.GC1202@neu.nirvana> References: <1176226908.3970.85.camel@localhost.localdomain> <20070410192317.GC1202@neu.nirvana> Message-ID: <200704102351.22748.ville.skytta@iki.fi> On Tuesday 10 April 2007, Axel Thimm wrote: > On Tue, Apr 10, 2007 at 12:41:48PM -0500, Tom spot Callaway wrote: > > Since some of the folks on the Committee have trouble attending our > > weekly meetings > > Sorry, I couldn't make it today and didn't know in advance either, so > could notify anyone. :/ Ditto. From petersen at redhat.com Wed Apr 11 01:54:08 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 11 Apr 2007 11:54:08 +1000 Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: <1176184707.25025.0.camel@rousalka.dyndns.org> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> Message-ID: <461C3FC0.3060005@redhat.com> Nicolas Mailhot wrote: > Nope. Their whole point is not to add a fontconfig dep to font packages Should bugs be filed against all fonts packages that currently require fontconfig? Jens From rc040203 at freenet.de Wed Apr 11 03:30:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 11 Apr 2007 05:30:07 +0200 Subject: [Fedora-packaging] Re: Fedora Packaging Committee Meeting Time Change In-Reply-To: <200704102351.22748.ville.skytta@iki.fi> References: <1176226908.3970.85.camel@localhost.localdomain> <20070410192317.GC1202@neu.nirvana> <200704102351.22748.ville.skytta@iki.fi> Message-ID: <1176262207.14629.81.camel@mccallum.corsepiu.local> On Tue, 2007-04-10 at 23:51 +0300, Ville Skytt? wrote: > On Tuesday 10 April 2007, Axel Thimm wrote: > > On Tue, Apr 10, 2007 at 12:41:48PM -0500, Tom spot Callaway wrote: > > > Since some of the folks on the Committee have trouble attending our > > > weekly meetings > > > > Sorry, I couldn't make it today and didn't know in advance either, so > > could notify anyone. :/ > > Ditto. Ditto - I was AFK for most of the time yesterday and didn't manage to return "in time". Ralf From nicolas.mailhot at laposte.net Wed Apr 11 07:57:55 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 09:57:55 +0200 (CEST) Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: <461C3FC0.3060005@redhat.com> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> <461C3FC0.3060005@redhat.com> Message-ID: <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> Le Mer 11 avril 2007 03:54, Jens Petersen a ?crit : > Nicolas Mailhot wrote: >> Nope. Their whole point is not to add a fontconfig dep to font packages > > Should bugs be filed against all fonts packages that currently require > fontconfig? IMHO yes. When this was formalized (around Bitstream Vera inclusion in fedora.us then FC) non adherence of font packages to any specific renderer was an explicit objective. (I'm speaking of truetype/opentype packages there, core fonts are a lost cause). The most one can do is conflict with old fontconfig packages if the rpm dumps a conf file in /etc/fonts, since fontconfig syntax has evolved over time. -- Nicolas Mailhot From dlutter at redhat.com Wed Apr 11 18:37:38 2007 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 11 Apr 2007 11:37:38 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176235700.30783.57.camel@localhost.localdomain> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> <1176229627.3970.88.camel@localhost.localdomain> <200704101514.23982.jkeating@redhat.com> <1176235700.30783.57.camel@localhost.localdomain> Message-ID: <1176316658.16085.72.camel@galia.watzmann.net> On Tue, 2007-04-10 at 13:08 -0700, Toshio Kuratomi wrote: > Two hours earlier is 8AM on the West Coast. I'm not commuting right now > so that ought to be doable for me at the moment. > > An hour later is fine. Later is fine, two hours earlier (8am PDT) would be pretty hard because of childcare issues. One hour earlier (9am PDT) works fine. David From orion at cora.nwra.com Wed Apr 11 21:04:54 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 11 Apr 2007 15:04:54 -0600 Subject: [Fedora-packaging] -devel arch dependencies Message-ID: <461D4D76.9070201@cora.nwra.com> Here's a question. Should -devel package requirements be of the form: Requires: package-devel.%{arch} I ask because of the following: # yum list libX11-devel Loading "installonlyn" plugin Setting up repositories Reading repository metadata in from local files Excluding Packages from Fedora Core 6 - x86_64 - Updates Finished Installed Packages libX11-devel.i386 1.0.3-6.fc6 installed Available Packages libX11-devel.x86_64 1.0.3-7.fc6 updates libX11-devel.i386 1.0.3-7.fc6 updates [root at apollo ~]# rpm -e libX11-devel error: Failed dependencies: libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.x86_64 libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.x86_64 libX11-devel is needed by (installed) mesa-libGL-devel-6.5.1-9.fc6.x86_64 libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 libX11-devel is needed by (installed) libXt-devel-1.0.2-3.1.fc6.i386 libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386 Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be satisfied by libX11-devel.i386? The needed libraries won't be there for linking. Can this be done in packaging, or does this need to be done in rpm? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From notting at redhat.com Wed Apr 11 21:03:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 11 Apr 2007 17:03:35 -0400 Subject: [Fedora-packaging] -devel arch dependencies In-Reply-To: <461D4D76.9070201@cora.nwra.com> References: <461D4D76.9070201@cora.nwra.com> Message-ID: <20070411210335.GD26122@nostromo.devel.redhat.com> Orion Poplawski (orion at cora.nwra.com) said: > Here's a question. Should -devel package requirements be of the form: > > Requires: package-devel.%{arch} Doesn't work, so... no. Bill From Axel.Thimm at ATrpms.net Wed Apr 11 21:08:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 23:08:19 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <461D4D76.9070201@cora.nwra.com> References: <461D4D76.9070201@cora.nwra.com> Message-ID: <20070411210819.GB32753@neu.nirvana> On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote: > Here's a question. Should -devel package requirements be of the form: > > Requires: package-devel.%{arch} On what rpm versions does this work? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dev at nigelj.com Thu Apr 12 02:33:06 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 12 Apr 2007 14:33:06 +1200 Subject: [Fedora-packaging] Issues with Ocaml and Static Linking Message-ID: <461D9A62.2070006@nigelj.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, While putting in a couple of packages for Extras Review I've stumbled into a couple of issues regarding how Ocaml links libraries and how the Fedora Packaging Guidelines are set. My packages in question are: ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815) Basically, ocamlSDL and camlimages produce two sets of libraries (a set of dynamic libraries, and another set for development etc), sadly when other packages like freetennis build, they staticly link to libraries such as camlimages/ocamlSDL. I found it semi-suspect when I built freetennis, and hence why I asked on bugzilla when I posted the three packages for review, however I did some more questioning today and after a quick IRC discussion in #ocaml was told: 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries right? 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for dynamic loading as static loading. Looking at my installed files on my laptop, lablgl, lablgtk and labltk (as well as the main ocaml package) store .a, .cma and .cmxa files in /usr/lib/ocaml (and subfolders). As I'm only new to Fedora packaging, could someone please advise on where I should from here on the matter and what the position of FESCO is on Ocaml static libraries, and where I should go from here. Thanks, Nigel Jones -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGHZpipldg9bRmG6kRAk8IAJ9JepuGRc7m3AH35XFhRUKG+w1xYgCgis+F BhyetHeiFfS5U9svDsy9Ufc= =RmdN -----END PGP SIGNATURE----- From pmatilai at laiskiainen.org Thu Apr 12 06:55:12 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 12 Apr 2007 09:55:12 +0300 (EEST) Subject: [Fedora-packaging] -devel arch dependencies In-Reply-To: <20070411210335.GD26122@nostromo.devel.redhat.com> References: <461D4D76.9070201@cora.nwra.com> <20070411210335.GD26122@nostromo.devel.redhat.com> Message-ID: On Wed, 11 Apr 2007, Bill Nottingham wrote: > Orion Poplawski (orion at cora.nwra.com) said: >> Here's a question. Should -devel package requirements be of the form: >> >> Requires: package-devel.%{arch} > > Doesn't work, so... no. Doesn't work, but interesting timing :) https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html - Panu - From skvidal at linux.duke.edu Thu Apr 12 07:06:51 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Apr 2007 03:06:51 -0400 Subject: [Fedora-packaging] -devel arch dependencies In-Reply-To: References: <461D4D76.9070201@cora.nwra.com> <20070411210335.GD26122@nostromo.devel.redhat.com> Message-ID: <1176361612.13177.44.camel@cutter> On Thu, 2007-04-12 at 09:55 +0300, Panu Matilainen wrote: > On Wed, 11 Apr 2007, Bill Nottingham wrote: > > > Orion Poplawski (orion at cora.nwra.com) said: > >> Here's a question. Should -devel package requirements be of the form: > >> > >> Requires: package-devel.%{arch} > > > > Doesn't work, so... no. > > Doesn't work, but interesting timing :) > https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html > I'd like to offer a HELL NO in reference to that syntax. -sv From nicolas.mailhot at laposte.net Thu Apr 12 07:32:46 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Apr 2007 09:32:46 +0200 (CEST) Subject: [Fedora-packaging] -devel arch dependencies In-Reply-To: <1176361612.13177.44.camel@cutter> References: <461D4D76.9070201@cora.nwra.com> <20070411210335.GD26122@nostromo.devel.redhat.com> <1176361612.13177.44.camel@cutter> Message-ID: <1976.192.54.193.51.1176363166.squirrel@rousalka.dyndns.org> Le Jeu 12 avril 2007 09:06, seth vidal a ?crit : > On Thu, 2007-04-12 at 09:55 +0300, Panu Matilainen wrote: >> On Wed, 11 Apr 2007, Bill Nottingham wrote: >> >> > Orion Poplawski (orion at cora.nwra.com) said: >> >> Here's a question. Should -devel package requirements be of the >> form: >> >> >> >> Requires: package-devel.%{arch} >> > >> > Doesn't work, so... no. >> >> Doesn't work, but interesting timing :) >> https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html >> > > I'd like to offer a HELL NO in reference to that syntax. Please someone explain JBJ that spec syntax must be parseable by humans, and Arch(foo) will only make packagers try Version(foo). Sanity demands foo(arch=x and version >y) if he wants packagers to tokenize EVR for him -- Nicolas Mailhot From skvidal at linux.duke.edu Thu Apr 12 07:51:07 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Apr 2007 03:51:07 -0400 Subject: [Fedora-packaging] -devel arch dependencies In-Reply-To: <1976.192.54.193.51.1176363166.squirrel@rousalka.dyndns.org> References: <461D4D76.9070201@cora.nwra.com> <20070411210335.GD26122@nostromo.devel.redhat.com> <1176361612.13177.44.camel@cutter> <1976.192.54.193.51.1176363166.squirrel@rousalka.dyndns.org> Message-ID: <1176364267.13177.46.camel@cutter> On Thu, 2007-04-12 at 09:32 +0200, Nicolas Mailhot wrote: > Le Jeu 12 avril 2007 09:06, seth vidal a ?crit : > > On Thu, 2007-04-12 at 09:55 +0300, Panu Matilainen wrote: > >> On Wed, 11 Apr 2007, Bill Nottingham wrote: > >> > >> > Orion Poplawski (orion at cora.nwra.com) said: > >> >> Here's a question. Should -devel package requirements be of the > >> form: > >> >> > >> >> Requires: package-devel.%{arch} > >> > > >> > Doesn't work, so... no. > >> > >> Doesn't work, but interesting timing :) > >> https://lists.dulug.duke.edu/pipermail/rpm-devel/2007-April/002260.html > >> > > > > I'd like to offer a HELL NO in reference to that syntax. > > Please someone explain JBJ that spec syntax must be parseable by humans, > and Arch(foo) will only make packagers try Version(foo). > > Sanity demands foo(arch=x and version >y) if he wants packagers to > tokenize EVR for him how about arch >= i386 so that would include x86_64, too, right? :) /me runs -sv From nicolas.mailhot at laposte.net Thu Apr 12 07:53:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Apr 2007 09:53:45 +0200 (CEST) Subject: [Fedora-packaging] -devel arch dependencies In-Reply-To: <1176364267.13177.46.camel@cutter> References: <461D4D76.9070201@cora.nwra.com> <20070411210335.GD26122@nostromo.devel.redhat.com> <1176361612.13177.44.camel@cutter> <1976.192.54.193.51.1176363166.squirrel@rousalka.dyndns.org> <1176364267.13177.46.camel@cutter> Message-ID: <25422.192.54.193.51.1176364425.squirrel@rousalka.dyndns.org> Le Jeu 12 avril 2007 09:51, seth vidal a ?crit : > On Thu, 2007-04-12 at 09:32 +0200, Nicolas Mailhot wrote: >> Le Jeu 12 avril 2007 09:06, seth vidal a ?crit : >> > I'd like to offer a HELL NO in reference to that syntax. >> >> Please someone explain JBJ that spec syntax must be parseable by humans, >> and Arch(foo) will only make packagers try Version(foo). >> >> Sanity demands foo(arch=x and version >y) if he wants packagers to >> tokenize EVR for him > > how about arch >= i386 > > so that would include x86_64, too, right? :) foo(arch=i386 or arch=x86_64) ? > /me runs You can't escape rpm indefinitely :) -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Thu Apr 12 09:31:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Apr 2007 11:31:37 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <461D4D76.9070201@cora.nwra.com> References: <461D4D76.9070201@cora.nwra.com> Message-ID: <20070412093137.GF32753@neu.nirvana> On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote: > Here's a question. Should -devel package requirements be of the form: > > Requires: package-devel.%{arch} Maybe it makes more sense to disallow rpm from satisfying cross-arch dependencies at all. noarch belongs to all archs in this sense. E.g. in the noarch, i386, x86_64 world, don't allow i386 packages to satisfy depednencies of x86_64 and vice-versa. > I ask because of the following: > > # yum list libX11-devel > Loading "installonlyn" plugin > Setting up repositories > Reading repository metadata in from local files > Excluding Packages from Fedora Core 6 - x86_64 - Updates > Finished > Installed Packages > libX11-devel.i386 1.0.3-6.fc6 installed > Available Packages > libX11-devel.x86_64 1.0.3-7.fc6 updates > libX11-devel.i386 1.0.3-7.fc6 updates > [root at apollo ~]# rpm -e libX11-devel > error: Failed dependencies: > libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 > libX11-devel is needed by (installed) > libXt-devel-1.0.2-3.1.fc6.x86_64 > libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 > libX11-devel is needed by (installed) > libXext-devel-1.0.1-2.1.x86_64 > libX11-devel is needed by (installed) > mesa-libGL-devel-6.5.1-9.fc6.x86_64 > libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 > libX11-devel is needed by (installed) > libXt-devel-1.0.2-3.1.fc6.i386 > libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386 > > > Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be > satisfied by libX11-devel.i386? The needed libraries won't be there for > linking. > > Can this be done in packaging, or does this need to be done in rpm? > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu Apr 12 11:20:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 07:20:29 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412093137.GF32753@neu.nirvana> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> Message-ID: <200704120720.33103.jkeating@redhat.com> On Thursday 12 April 2007 05:31:37 Axel Thimm wrote: > noarch belongs to all archs in this > sense Except where they don't, when we really don't want a noarch package on a particular arch, and right now we don't have a good way of doing this :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Apr 12 12:05:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Apr 2007 14:05:02 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <200704120720.33103.jkeating@redhat.com> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <200704120720.33103.jkeating@redhat.com> Message-ID: <20070412120502.GH32753@neu.nirvana> On Thu, Apr 12, 2007 at 07:20:29AM -0400, Jesse Keating wrote: > On Thursday 12 April 2007 05:31:37 Axel Thimm wrote: > > noarch belongs to all archs in this sense > > Except where they don't, when we really don't want a noarch package on a > particular arch, and right now we don't have a good way of doing this :/ But that's a complete different topic, no? We're not talking about what to have in the repo, but when it is there, what to allow for fulfilling dependencies, e.g. build/runtime resolving of dependencies (rpm) vs repo construction policies (). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmatilai at laiskiainen.org Thu Apr 12 12:29:09 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 12 Apr 2007 15:29:09 +0300 (EEST) Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412093137.GF32753@neu.nirvana> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> Message-ID: On Thu, 12 Apr 2007, Axel Thimm wrote: > On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote: >> Here's a question. Should -devel package requirements be of the form: >> >> Requires: package-devel.%{arch} > > Maybe it makes more sense to disallow rpm from satisfying cross-arch > dependencies at all. noarch belongs to all archs in this > sense. E.g. in the noarch, i386, x86_64 world, don't allow i386 > packages to satisfy depednencies of x86_64 and vice-versa. That doesn't quite fly either, it's perfectly valid for a package to require eg "webclient" for viewing html content and the app doesn't care if the client is 32bit or 64bit, just as long as it does the job. >> I ask because of the following: >> >> # yum list libX11-devel >> Loading "installonlyn" plugin >> Setting up repositories >> Reading repository metadata in from local files >> Excluding Packages from Fedora Core 6 - x86_64 - Updates >> Finished >> Installed Packages >> libX11-devel.i386 1.0.3-6.fc6 installed >> Available Packages >> libX11-devel.x86_64 1.0.3-7.fc6 updates >> libX11-devel.i386 1.0.3-7.fc6 updates >> [root at apollo ~]# rpm -e libX11-devel >> error: Failed dependencies: >> libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.x86_64 >> libX11-devel is needed by (installed) >> libXt-devel-1.0.2-3.1.fc6.x86_64 >> libX11-devel is needed by (installed) libXmu-devel-1.0.2-5.x86_64 >> libX11-devel is needed by (installed) >> libXext-devel-1.0.1-2.1.x86_64 >> libX11-devel is needed by (installed) >> mesa-libGL-devel-6.5.1-9.fc6.x86_64 >> libX11-devel is needed by (installed) libXpm-devel-3.5.5-3.i386 >> libX11-devel is needed by (installed) >> libXt-devel-1.0.2-3.1.fc6.i386 >> libX11-devel is needed by (installed) libXext-devel-1.0.1-2.1.i386 >> >> >> Should the libXpm-devel-3.5.5-3.x86_64 requirement for "libX11-devel" be >> satisfied by libX11-devel.i386? The needed libraries won't be there for >> linking. >> >> Can this be done in packaging, or does this need to be done in rpm? I don't see why it couldn't be done in packaging with something like "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel package.. or some similar manual construct. Whether requiring yet more manual cruft to be added to almost each and every package is desirable or feasible is a whole another question :) - Panu - From Axel.Thimm at ATrpms.net Thu Apr 12 12:45:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Apr 2007 14:45:56 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> Message-ID: <20070412124556.GI32753@neu.nirvana> On Thu, Apr 12, 2007 at 03:29:09PM +0300, Panu Matilainen wrote: > On Thu, 12 Apr 2007, Axel Thimm wrote: > >On Wed, Apr 11, 2007 at 03:04:54PM -0600, Orion Poplawski wrote: > >>Here's a question. Should -devel package requirements be of the form: > >> > >>Requires: package-devel.%{arch} > > > >Maybe it makes more sense to disallow rpm from satisfying cross-arch > >dependencies at all. noarch belongs to all archs in this > >sense. E.g. in the noarch, i386, x86_64 world, don't allow i386 > >packages to satisfy depednencies of x86_64 and vice-versa. > > That doesn't quite fly either, it's perfectly valid for a package to > require eg "webclient" for viewing html content and the app doesn't care > if the client is 32bit or 64bit, just as long as it does the job. > I don't see why it couldn't be done in packaging with something like > "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package > and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel > package.. or some similar manual construct. Because ... see your own answer below :) > Whether requiring yet more manual cruft to be added to almost each and > every package is desirable or feasible is a whole another question :) Indeed, if we want to solve this it would have to be some solution that can leave the specfiles at peace. That's why I suggest to change rpm's interpretation instead of adding new syntax. Maybe the above isn't the best solution, yet, but perhaps it hints to a better one. E.g. I'd prefer to come to a solution where only "webclient" needs special treatment and new syntax, since that would mean touching a dozen packages and not some thousands :) But I feel that this is outside the packaging group's domain, we don't develop rpm. Maybe Orion should file a bug against rpm? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 12 12:52:00 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Apr 2007 14:52:00 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> Message-ID: <20070412145200.4c8e5d50@python3.es.egwn.lan> Panu Matilainen wrote : > I don't see why it couldn't be done in packaging with something like > "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package > and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel > package.. or some similar manual construct. > > Whether requiring yet more manual cruft to be added to almost each and > every package is desirable or feasible is a whole another question :) Hmmmm... I can't seem to remember why it is that we bloat some archs with that "multilib" hack in the first place... oh, yeah, the flash browser plugin! The only downsides being wasted disk space, wasted yum processing time, wasted bandwidth and missing documentations and translations for people trying to clean things up. Well... err... sorry for the flamebait... /me runs Matthias, still annoyed at "yum install gdb" trying to pull in almost an entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p (this said, on a quite simple FC6 x86_64 install on which I've done "yum remove glibc.i686" post-install, gnome-terminal crashes in some /usr/lib64/gconv/ library, which I suspect has something to do with multilib and rpm removing translations... but even after nearly two hours, I still couldn't figure out where the problem lies... glibc, some libgnome*... dunno...) -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2943.fc6 Load : 0.23 0.21 0.18 From mattdm at mattdm.org Thu Apr 12 13:06:07 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 12 Apr 2007 09:06:07 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412145200.4c8e5d50@python3.es.egwn.lan> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> Message-ID: <20070412130607.GA23134@jadzia.bu.edu> On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote: > Matthias, still annoyed at "yum install gdb" trying to pull in almost an > entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p Someday we'll convince Seth to come around on this. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Axel.Thimm at ATrpms.net Thu Apr 12 13:13:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Apr 2007 15:13:59 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412145200.4c8e5d50@python3.es.egwn.lan> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> Message-ID: <20070412131359.GK32753@neu.nirvana> On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote: > (this said, on a quite simple FC6 x86_64 install on which I've done > "yum remove glibc.i686" post-install, gnome-terminal crashes > in some /usr/lib64/gconv/ library, which I suspect has something to do > with multilib and rpm removing translations... but even after nearly > two hours, I still couldn't figure out where the problem lies... glibc, > some libgnome*... dunno...) Try rpm -Va 2>&1 | grep missing -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Apr 12 13:19:41 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Apr 2007 09:19:41 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412130607.GA23134@jadzia.bu.edu> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> Message-ID: <1176383981.13177.49.camel@cutter> On Thu, 2007-04-12 at 09:06 -0400, Matthew Miller wrote: > On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote: > > Matthias, still annoyed at "yum install gdb" trying to pull in almost an > > entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p > > Someday we'll convince Seth to come around on this. :) And how do we go about explaining to users on x86_64 machines why they have to jump through all these hoops to run firefox that'll work with plugins? -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 12 13:22:00 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Apr 2007 15:22:00 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412131359.GK32753@neu.nirvana> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412131359.GK32753@neu.nirvana> Message-ID: <20070412152200.1afe8c2a@python3.es.egwn.lan> Axel Thimm wrote : > On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote: > > (this said, on a quite simple FC6 x86_64 install on which I've done > > "yum remove glibc.i686" post-install, gnome-terminal crashes > > in some /usr/lib64/gconv/ library, which I suspect has something to do > > with multilib and rpm removing translations... but even after nearly > > two hours, I still couldn't figure out where the problem lies... glibc, > > some libgnome*... dunno...) > > Try rpm -Va 2>&1 | grep missing Done that, waaaaaaaayyyyy too many docs and translations gone. I forced a reinstall of the packages I thought could be the cause (i.e. glibc*, libgnome, gtk2/glib2 etc.) but without any apparent success. Anyway, my point was that from my POV multilib is ugly (I think we're all aware of that and all agree...), and that I still don't like the fact that it's forced upon all users by default (this is where opinions are much more mixed). Arch dependencies isn't something we would have to worry about if we weren't doing all of this ugly mixing of archs on single systems ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2943.fc6 Load : 0.40 0.25 0.20 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 12 13:24:44 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Apr 2007 15:24:44 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <1176383981.13177.49.camel@cutter> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> Message-ID: <20070412152444.6cbc2589@python3.es.egwn.lan> seth vidal wrote : > On Thu, 2007-04-12 at 09:06 -0400, Matthew Miller wrote: > > On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote: > > > Matthias, still annoyed at "yum install gdb" trying to pull in almost an > > > entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p > > > > Someday we'll convince Seth to come around on this. :) > > And how do we go about explaining to users on x86_64 machines why they > have to jump through all these hoops to run firefox that'll work with > plugins? s/plugins/proprietary plugins only available for 32bit x86/ ...and the answer could be : Shouldn't we care about as much as how to install proprietary video drivers or patent encumbered codecs? :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2943.fc6 Load : 0.17 0.14 0.15 From skvidal at linux.duke.edu Thu Apr 12 13:31:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Apr 2007 09:31:11 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412152444.6cbc2589@python3.es.egwn.lan> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412152444.6cbc2589@python3.es.egwn.lan> Message-ID: <1176384671.13177.56.camel@cutter> On Thu, 2007-04-12 at 15:24 +0200, Matthias Saou wrote: > seth vidal wrote : > > > On Thu, 2007-04-12 at 09:06 -0400, Matthew Miller wrote: > > > On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote: > > > > Matthias, still annoyed at "yum install gdb" trying to pull in almost an > > > > entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p > > > > > > Someday we'll convince Seth to come around on this. :) > > > > And how do we go about explaining to users on x86_64 machines why they > > have to jump through all these hoops to run firefox that'll work with > > plugins? > > s/plugins/proprietary plugins only available for 32bit x86/ > > ...and the answer could be : Shouldn't we care about as much as how to > install proprietary video drivers or patent encumbered codecs? :-) okie doke. I can understand that. If you don't want multilib pkgs installed then that's do-able. But I'm not the person to convince of it and I don't think it comes back to me to decide this for the distribution. -sv From Axel.Thimm at ATrpms.net Thu Apr 12 13:37:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 12 Apr 2007 15:37:42 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412152200.1afe8c2a@python3.es.egwn.lan> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412131359.GK32753@neu.nirvana> <20070412152200.1afe8c2a@python3.es.egwn.lan> Message-ID: <20070412133742.GM32753@neu.nirvana> On Thu, Apr 12, 2007 at 03:22:00PM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > On Thu, Apr 12, 2007 at 02:52:00PM +0200, Matthias Saou wrote: > > > (this said, on a quite simple FC6 x86_64 install on which I've done > > > "yum remove glibc.i686" post-install, gnome-terminal crashes > > > in some /usr/lib64/gconv/ library, which I suspect has something to do > > > with multilib and rpm removing translations... but even after nearly > > > two hours, I still couldn't figure out where the problem lies... glibc, > > > some libgnome*... dunno...) > > > > Try rpm -Va 2>&1 | grep missing > > Done that, waaaaaaaayyyyy too many docs and translations gone. I forced > a reinstall of the packages I thought could be the cause (i.e. glibc*, > libgnome, gtk2/glib2 etc.) but without any apparent success. > > Anyway, my point was that from my POV multilib is ugly (I think we're > all aware of that and all agree...), In fact, I like multilib/multiarch. It isn't the general concept that sucks, but our overwrite concept and the buggy implementation in rpm. > and that I still don't like the fact that it's forced upon all users > by default (this is where opinions are much more mixed). > > Arch dependencies isn't something we would have to worry about if we > weren't doing all of this ugly mixing of archs on single systems ;-) > > Matthias -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Apr 12 13:45:45 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Apr 2007 08:45:45 -0500 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412133742.GM32753@neu.nirvana> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412131359.GK32753@neu.nirvana> <20070412152200.1afe8c2a@python3.es.egwn.lan> <20070412133742.GM32753@neu.nirvana> Message-ID: <461E3809.7080601@math.unl.edu> Axel Thimm wrote: > On Thu, Apr 12, 2007 at 03:22:00PM +0200, Matthias Saou wrote: >>> Try rpm -Va 2>&1 | grep missing >> Done that, waaaaaaaayyyyy too many docs and translations gone. I forced >> a reinstall of the packages I thought could be the cause (i.e. glibc*, >> libgnome, gtk2/glib2 etc.) but without any apparent success. >> >> Anyway, my point was that from my POV multilib is ugly (I think we're >> all aware of that and all agree...), > > In fact, I like multilib/multiarch. It isn't the general concept that > sucks, but our overwrite concept and the buggy implementation in rpm. And buggy packages marking items as %doc that aren't truly optional. -- Rex From mattdm at mattdm.org Thu Apr 12 14:52:42 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 12 Apr 2007 10:52:42 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <1176383981.13177.49.camel@cutter> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> Message-ID: <20070412145242.GA30912@jadzia.bu.edu> On Thu, Apr 12, 2007 at 09:19:41AM -0400, seth vidal wrote: > > > Matthias, still annoyed at "yum install gdb" trying to pull in almost an > > > entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p > > Someday we'll convince Seth to come around on this. :) > And how do we go about explaining to users on x86_64 machines why they > have to jump through all these hoops to run firefox that'll work with > plugins? yum install firefox.i386 ? With the default being to match "bestarch" if none is given. Okay, what am I missing? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rc040203 at freenet.de Thu Apr 12 14:55:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 Apr 2007 16:55:11 +0200 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176316658.16085.72.camel@galia.watzmann.net> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> <1176229627.3970.88.camel@localhost.localdomain> <200704101514.23982.jkeating@redhat.com> <1176235700.30783.57.camel@localhost.localdomain> <1176316658.16085.72.camel@galia.watzmann.net> Message-ID: <1176389711.14629.237.camel@mccallum.corsepiu.local> On Wed, 2007-04-11 at 11:37 -0700, David Lutterkort wrote: > On Tue, 2007-04-10 at 13:08 -0700, Toshio Kuratomi wrote: > > Two hours earlier is 8AM on the West Coast. I'm not commuting right now > > so that ought to be doable for me at the moment. > > > > An hour later is fine. An hour later (20:00 CEST/18:00 UTC instead of 19:00 CEST/17:00 UTC) would be worse for me. > Later is fine, two hours earlier (8am PDT) would be pretty hard because > of childcare issues. One hour earlier (9am PDT) works fine. As I already wrote before, anything earlier than 17:00 UTC (19:00 CEST) would work for me. Ralf From skvidal at linux.duke.edu Thu Apr 12 14:59:11 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Apr 2007 10:59:11 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412145242.GA30912@jadzia.bu.edu> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> Message-ID: <1176389951.19158.2.camel@cutter> On Thu, 2007-04-12 at 10:52 -0400, Matthew Miller wrote: > On Thu, Apr 12, 2007 at 09:19:41AM -0400, seth vidal wrote: > > > > Matthias, still annoyed at "yum install gdb" trying to pull in almost an > > > > entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p > > > Someday we'll convince Seth to come around on this. :) > > And how do we go about explaining to users on x86_64 machines why they > > have to jump through all these hoops to run firefox that'll work with > > plugins? > > yum install firefox.i386 ? > > With the default being to match "bestarch" if none is given. > > Okay, what am I missing? :) "Why am I installing this older arch on my system?" "What's an 'arch'?" "Why can't fedora just work?" "Why do I have to mess with all this stuff just to see web pages?" -sv From tcallawa at redhat.com Thu Apr 12 14:57:44 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 12 Apr 2007 09:57:44 -0500 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412145242.GA30912@jadzia.bu.edu> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> Message-ID: <1176389864.3970.154.camel@localhost.localdomain> On Thu, 2007-04-12 at 10:52 -0400, Matthew Miller wrote: > On Thu, Apr 12, 2007 at 09:19:41AM -0400, seth vidal wrote: > > > > Matthias, still annoyed at "yum install gdb" trying to pull in almost an > > > > entire "compat" 32bit system... yeah, "yum install gdb.x86_64" :-p > > > Someday we'll convince Seth to come around on this. :) > > And how do we go about explaining to users on x86_64 machines why they > > have to jump through all these hoops to run firefox that'll work with > > plugins? > > yum install firefox.i386 ? > > With the default being to match "bestarch" if none is given. > > Okay, what am I missing? :) FWIW, I'm still not sure why we don't do this: x86_64 repo (with all x86_64 packages and firefox.i386 and deps as ONLY i386 packages) i386 repo (with all i386 packages) x86_64 installs include yum config for i386 repo, but it is disabled by default. You want multilib, enable the i386 repo. I doubt that we have any statistics on people willingly using multilib, but I know I got it on my x86_64 machine and I sure as hell didn't want it for anything besides firefox. ~spot From mattdm at mattdm.org Thu Apr 12 15:07:07 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 12 Apr 2007 11:07:07 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <1176389864.3970.154.camel@localhost.localdomain> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> Message-ID: <20070412150707.GA824@jadzia.bu.edu> On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote: > I doubt that we have any statistics on people willingly using multilib, > but I know I got it on my x86_64 machine and I sure as hell didn't want > it for anything besides firefox. +1,000,000. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Apr 12 15:24:23 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 12 Apr 2007 11:24:23 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <1176389951.19158.2.camel@cutter> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389951.19158.2.camel@cutter> Message-ID: <20070412152423.GB824@jadzia.bu.edu> On Thu, Apr 12, 2007 at 10:59:11AM -0400, seth vidal wrote: > > yum install firefox.i386 ? > > With the default being to match "bestarch" if none is given. > > Okay, what am I missing? :) > "Why am I installing this older arch on my system?" > "What's an 'arch'?" > "Why can't fedora just work?" > "Why do I have to mess with all this stuff just to see web pages?" Anaconda could run with bestarch=0 to cover this. Hmmm, actually, is firefox really the only case we care about? Warren's "firefox-32" kludge says in the spec file "Unfortunately, we cannot have a Requires line that explicitly means /usr/lib/ 32bit firefox." But using "Requires: /usr/lib/firefox-2.0.0.3/firefox-bin" works for me. That's a bit annoying because of the version number -- either the 32-bit package would have to provide a unique, non-versioned file [*], or the firefox-32 package would have to be updated simultaneously with each firefox release. But having that requires line in there makes it so if I yum install the x86_64 firefox-32, it pulls in firefox.i386.... This all seems so easy I *must* be missing something. :) * other than "/etc/gre.d/gre.conf", which is too kludgy even for me. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Thu Apr 12 15:39:38 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Apr 2007 10:39:38 -0500 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176389711.14629.237.camel@mccallum.corsepiu.local> References: <1176226908.3970.85.camel@localhost.localdomain> <200704101350.13311.jkeating@redhat.com> <1176229627.3970.88.camel@localhost.localdomain> <200704101514.23982.jkeating@redhat.com> <1176235700.30783.57.camel@localhost.localdomain> <1176316658.16085.72.camel@galia.watzmann.net> <1176389711.14629.237.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> As I already wrote before, anything earlier than 17:00 UTC (19:00 RC> CEST) would work for me. It seems that the basic conflict here is between Ralf not being able to make it at all and f13's lunch hour. Does f13 have the only conflict with 16:00UTC? Is, say, 16:30UTC any better (or worse) for anyone? - J< From jkeating at redhat.com Thu Apr 12 15:46:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 11:46:02 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: References: <1176226908.3970.85.camel@localhost.localdomain> <1176389711.14629.237.camel@mccallum.corsepiu.local> Message-ID: <200704121146.02846.jkeating@redhat.com> On Thursday 12 April 2007 11:39:38 Jason L Tibbitts III wrote: > It seems that the basic conflict here is between Ralf not being able > to make it at all and f13's lunch hour. ?Does f13 have the only > conflict with 16:00UTC? ?Is, say, 16:30UTC any better (or worse) for > anyone? What's wrong with 15:00UTC? I didn't see anybody having a conflict there, unless Toshio gets a new job. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Apr 12 15:47:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Apr 2007 17:47:04 +0200 (CEST) Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412150707.GA824@jadzia.bu.edu> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> <20070412150707.GA824@jadzia.bu.edu> Message-ID: <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> Le Jeu 12 avril 2007 17:07, Matthew Miller a ?crit : > On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote: >> I doubt that we have any statistics on people willingly using multilib, >> but I know I got it on my x86_64 machine and I sure as hell didn't want >> it for anything besides firefox. > > +1,000,000. :) I'm full 64bit on my box precisely because flash was not worth the pain of dealing with multilib -- Nicolas Mailhot From a.badger at gmail.com Thu Apr 12 16:46:04 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 12 Apr 2007 09:46:04 -0700 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <200704121146.02846.jkeating@redhat.com> References: <1176226908.3970.85.camel@localhost.localdomain> <1176389711.14629.237.camel@mccallum.corsepiu.local> <200704121146.02846.jkeating@redhat.com> Message-ID: <1176396364.17485.0.camel@localhost.localdomain> On Thu, 2007-04-12 at 11:46 -0400, Jesse Keating wrote: > On Thursday 12 April 2007 11:39:38 Jason L Tibbitts III wrote: > > It seems that the basic conflict here is between Ralf not being able > > to make it at all and f13's lunch hour. Does f13 have the only > > conflict with 16:00UTC? Is, say, 16:30UTC any better (or worse) for > > anyone? > > What's wrong with 15:00UTC? I didn't see anybody having a conflict there, > unless Toshio gets a new job. > lutter can't make it. -Toshio -------------- 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 rc040203 at freenet.de Thu Apr 12 16:55:05 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 Apr 2007 18:55:05 +0200 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176396364.17485.0.camel@localhost.localdomain> References: <1176226908.3970.85.camel@localhost.localdomain> <1176389711.14629.237.camel@mccallum.corsepiu.local> <200704121146.02846.jkeating@redhat.com> <1176396364.17485.0.camel@localhost.localdomain> Message-ID: <1176396905.14629.258.camel@mccallum.corsepiu.local> On Thu, 2007-04-12 at 09:46 -0700, Toshio Kuratomi wrote: > On Thu, 2007-04-12 at 11:46 -0400, Jesse Keating wrote: > > On Thursday 12 April 2007 11:39:38 Jason L Tibbitts III wrote: > > > It seems that the basic conflict here is between Ralf not being able > > > to make it at all and f13's lunch hour. Does f13 have the only > > > conflict with 16:00UTC? Is, say, 16:30UTC any better (or worse) for > > > anyone? > > > > What's wrong with 15:00UTC? Would be fine with me. > I didn't see anybody having a conflict there, > > unless Toshio gets a new job. > > > lutter can't make it. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 12 18:33:10 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Apr 2007 20:33:10 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> <20070412150707.GA824@jadzia.bu.edu> <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> Message-ID: <20070412203310.1d48e045@python3.es.egwn.lan> Nicolas Mailhot wrote : > Le Jeu 12 avril 2007 17:07, Matthew Miller a ?crit : > > On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote: > >> I doubt that we have any statistics on people willingly using multilib, > >> but I know I got it on my x86_64 machine and I sure as hell didn't want > >> it for anything besides firefox. > > > > +1,000,000. :) > > I'm full 64bit on my box precisely because flash was not worth the pain of > dealing with multilib The only computer where I have left multilib packages installed is my main workstation, to get 32bit firefox, but in my case too it's the only thing I wanted... that's the first issue. The second issue is yum's default behaviour of installing all available archs for the requested package, which annoys me quite a lot. Today alone I had to re-run yum quite a few times after wanting to install some devel packages I needed to phpize some PHP modules... no, I don't want the 32bit devel package! ;-) Oh, silly question, but : When installing both firefox packages, is the 32bit version run by default!? If so, how come, and is it the same for all other packages (I seem to have quite a few installed as both 32 and 64 bit and I'd prefer to be running the native versions) or does firefox already have some kind of special treatment? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2943.fc6 Load : 0.17 0.18 0.18 From tcallawa at redhat.com Thu Apr 12 18:35:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 12 Apr 2007 13:35:34 -0500 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412203310.1d48e045@python3.es.egwn.lan> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> <20070412150707.GA824@jadzia.bu.edu> <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> <20070412203310.1d48e045@python3.es.egwn.lan> Message-ID: <1176402934.3970.179.camel@localhost.localdomain> On Thu, 2007-04-12 at 20:33 +0200, Matthias Saou wrote: > Oh, silly question, but : When installing both firefox packages, is the > 32bit version run by default!? If so, how come, and is it the same for > all other packages (I seem to have quite a few installed as both 32 and > 64 bit and I'd prefer to be running the native versions) or does > firefox already have some kind of special treatment? No, the 64bit version is. MOZ_ARCH=$(uname -m) case $MOZ_ARCH in x86_64 | ia64 | s390 ) MOZ_LIB_DIR="/usr/lib64" SECONDARY_LIB_DIR="/usr/lib" ;; * ) MOZ_LIB_DIR="/usr/lib" SECONDARY_LIB_DIR="/usr/lib64" ;; esac if [ ! -x $MOZ_LIB_DIR/firefox-2.0.0.3/firefox-bin ]; then if [ ! -x $SECONDARY_LIB_DIR/firefox-2.0.0.3/firefox-bin ]; then echo "Error: $MOZ_LIB_DIR/firefox-2.0.0.3/firefox-bin not found" if [ -d $SECONDARY_LIB_DIR ]; then echo " $SECONDARY_LIB_DIR/firefox-2.0.0.3/firefox-bin not found" fi exit 1 fi MOZ_LIB_DIR="$SECONDARY_LIB_DIR" fi ~spot From mattdm at mattdm.org Thu Apr 12 18:53:07 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 12 Apr 2007 14:53:07 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412203310.1d48e045@python3.es.egwn.lan> References: <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> <20070412150707.GA824@jadzia.bu.edu> <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> <20070412203310.1d48e045@python3.es.egwn.lan> Message-ID: <20070412185307.GA21836@jadzia.bu.edu> On Thu, Apr 12, 2007 at 08:33:10PM +0200, Matthias Saou wrote: > Oh, silly question, but : When installing both firefox packages, is the > 32bit version run by default!? If so, how come, and is it the same for > all other packages (I seem to have quite a few installed as both 32 and > 64 bit and I'd prefer to be running the native versions) or does > firefox already have some kind of special treatment? 64 by default. Install "firefox-32" from extras to get an icon that runs the 32-bit version. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Thu Apr 12 19:02:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Apr 2007 21:02:01 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412203310.1d48e045@python3.es.egwn.lan> References: <461D4D76.9070201@cora.nwra.com> <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> <20070412150707.GA824@jadzia.bu.edu> <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> <20070412203310.1d48e045@python3.es.egwn.lan> Message-ID: <461E8229.5060704@leemhuis.info> Matthias Saou schrieb: > Nicolas Mailhot wrote : >> Le Jeu 12 avril 2007 17:07, Matthew Miller a ?crit : >>> On Thu, Apr 12, 2007 at 09:57:44AM -0500, Tom spot Callaway wrote: >>>> I doubt that we have any statistics on people willingly using multilib, >>>> but I know I got it on my x86_64 machine and I sure as hell didn't want >>>> it for anything besides firefox. >>> +1,000,000. :) >> I'm full 64bit on my box precisely because flash was not worth the pain of >> dealing with multilib > The only computer where I have left multilib packages installed is my > main workstation, to get 32bit firefox, but in my case too it's the > only thing I wanted... that's the first issue. Well, I have firefox.i386 on my x86_64 machines, too. The only other x86-apps I use now and then is acroread (which has some i386 deps), where evince doesn't work (forms). > The second issue is yum's default behaviour of installing all available > archs for the requested package, which annoys me quite a lot. Today > alone I had to re-run yum quite a few times after wanting to install > some devel packages I needed to phpize some PHP modules... no, I don't > want the 32bit devel package! ;-) +1 -- Agreed. Is really bad for *-devel.i386 packages IMHO, as they track in lots of i386-userland packages that are hard to get rid of cleanly, because - the bug of rpm that removes some of the some files that are parts of both the i386 and the x86_64 package (docs for example iirc) - "package-cleanup --leaves all" doesn't find all of them (#235496) - something as I just forgot again I actually had a rant about it in my blog some days ago http://thorstenl.blogspot.com/2007/04/exclude-develi386.html (which received a reply from dwmw2 at http://www.advogato.org/person/dwmw2/diary.html?start=160 ) Maybe we should move this discussion to fedora-devel? This is something for FESCo afaics, and not for the PC. > [...] Cu thl From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 12 19:09:47 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Apr 2007 21:09:47 +0200 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412185307.GA21836@jadzia.bu.edu> References: <20070412093137.GF32753@neu.nirvana> <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> <20070412150707.GA824@jadzia.bu.edu> <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> <20070412203310.1d48e045@python3.es.egwn.lan> <20070412185307.GA21836@jadzia.bu.edu> Message-ID: <20070412210947.6f967013@python3.es.egwn.lan> Matthew Miller wrote : > On Thu, Apr 12, 2007 at 08:33:10PM +0200, Matthias Saou wrote: > > Oh, silly question, but : When installing both firefox packages, is the > > 32bit version run by default!? If so, how come, and is it the same for > > all other packages (I seem to have quite a few installed as both 32 and > > 64 bit and I'd prefer to be running the native versions) or does > > firefox already have some kind of special treatment? > > 64 by default. Install "firefox-32" from extras to get an icon that runs the > 32-bit version. Ok, then the current situation doesn't make much sense to me since it still requires some "manual work", i.e. either : - Install that firefox-32 package (and/or) - Remove the x86_64 firefox package I did the latter, but IIRC it is preventing me from installing some apps that are only available in 64bit and require the gecko engine which still hasn't been split out. Anyway, in the end my vote would be to change yum's behaviour from "install all available archs of the latest version" to "install best available arch of the latest version" when no arch is specified, and not have anaconda install any compat 32bit packages by default. As a side note, this is something I have always found quite annoying too : Any explicit package requirement from within a package also "triggers" the installation of all available archs (which is actually coherent with the current behavior, but annoying nevertheless). Example : If your package explicitly "Requires: curl" although it only really requires libcurl.so.3, which rpm also added automatically, you'll end up with curl.i386 and dragging in all of its dependencies. Without the explicit requirement, only curl.x86_64 would have been necessary. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2943.fc6 Load : 0.17 0.16 0.18 From mattdm at mattdm.org Thu Apr 12 19:13:54 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 12 Apr 2007 15:13:54 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412210947.6f967013@python3.es.egwn.lan> References: <20070412145200.4c8e5d50@python3.es.egwn.lan> <20070412130607.GA23134@jadzia.bu.edu> <1176383981.13177.49.camel@cutter> <20070412145242.GA30912@jadzia.bu.edu> <1176389864.3970.154.camel@localhost.localdomain> <20070412150707.GA824@jadzia.bu.edu> <13636.192.54.193.51.1176392824.squirrel@rousalka.dyndns.org> <20070412203310.1d48e045@python3.es.egwn.lan> <20070412185307.GA21836@jadzia.bu.edu> <20070412210947.6f967013@python3.es.egwn.lan> Message-ID: <20070412191354.GA23867@jadzia.bu.edu> On Thu, Apr 12, 2007 at 09:09:47PM +0200, Matthias Saou wrote: > > > Oh, silly question, but : When installing both firefox packages, is the > > > 32bit version run by default!? If so, how come, and is it the same for > > > all other packages (I seem to have quite a few installed as both 32 and > > > 64 bit and I'd prefer to be running the native versions) or does > > > firefox already have some kind of special treatment? > > 64 by default. Install "firefox-32" from extras to get an icon that runs the > > 32-bit version. > Ok, then the current situation doesn't make much sense to me since it > still requires some "manual work", i.e. either : > - Install that firefox-32 package > (and/or) > - Remove the x86_64 firefox package Good point. > Anyway, in the end my vote would be to change yum's behaviour from > "install all available archs of the latest version" to "install best > available arch of the latest version" when no arch is specified, and > not have anaconda install any compat 32bit packages by default. Plus we can add in the firefox-32 package if need be, if there's not something I'm missing about the dep change that makes it also pull in the 32-bit package. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ville.skytta at iki.fi Thu Apr 12 19:14:15 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 12 Apr 2007 22:14:15 +0300 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412124556.GI32753@neu.nirvana> References: <461D4D76.9070201@cora.nwra.com> <20070412124556.GI32753@neu.nirvana> Message-ID: <200704122214.15636.ville.skytta@iki.fi> On Thursday 12 April 2007, Axel Thimm wrote: > On Thu, Apr 12, 2007 at 03:29:09PM +0300, Panu Matilainen wrote: > > > I don't see why it couldn't be done in packaging with something like > > "Provides: %{name}.%{_arch} = %{version}-%{release}" in the main package > > and "Requires: %{name}.%{_arch} = %{version}-%{release}" in the -devel > > package.. or some similar manual construct. > > Because ... see your own answer below :) > > > Whether requiring yet more manual cruft to be added to almost each and > > every package is desirable or feasible is a whole another question :) > > Indeed, if we want to solve this it would have to be some solution > that can leave the specfiles at peace. Making rpmbuild autogenerate the Provides would probably be pretty easy. For the requires, it'd be pretty much a matter of adding the .$arch to the dependencies that are already explicitly listed in specfiles. By the way, %{_arch} is not the thing to use for this, %{_target_cpu} would be closer but not quite there either; dunno if a suitable variable actually exists. Think eg. building a package for i686 that has a dependency on something of the same arch which needs to be added explicitly in the specfile - i386, i486, i586 and/or i686 of that dependency would likely work. From ville.skytta at iki.fi Thu Apr 12 19:24:22 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 12 Apr 2007 22:24:22 +0300 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting Time Change In-Reply-To: <1176396364.17485.0.camel@localhost.localdomain> References: <1176226908.3970.85.camel@localhost.localdomain> <200704121146.02846.jkeating@redhat.com> <1176396364.17485.0.camel@localhost.localdomain> Message-ID: <200704122224.22377.ville.skytta@iki.fi> On Thursday 12 April 2007, Toshio Kuratomi wrote: > On Thu, 2007-04-12 at 11:46 -0400, Jesse Keating wrote: > > > What's wrong with 15:00UTC? I didn't see anybody having a conflict > > there, unless Toshio gets a new job. > > lutter can't make it. Me neither in non-DST times. During DST it'd be possible, but I'd probably be constantly a bit late. From jkeating at redhat.com Thu Apr 12 19:31:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 15:31:03 -0400 Subject: [Fedora-packaging] Re: -devel arch dependencies In-Reply-To: <20070412210947.6f967013@python3.es.egwn.lan> References: <20070412093137.GF32753@neu.nirvana> <20070412185307.GA21836@jadzia.bu.edu> <20070412210947.6f967013@python3.es.egwn.lan> Message-ID: <200704121531.06261.jkeating@redhat.com> On Thursday 12 April 2007 15:09:47 Matthias Saou wrote: > I did the latter, but IIRC it is preventing me from installing some > apps that are only available in 64bit and require the gecko engine > which still hasn't been split out. And it won't either. Mozilla decided that they don't want gecko to be a platform. > Anyway, in the end my vote would be to change yum's behaviour from > "install all available archs of the latest version" to "install best > available arch of the latest version" when no arch is specified, and > not have anaconda install any compat 32bit packages by default. > > As a side note, this is something I have always found quite annoying > too : Any explicit package requirement from within a package also > "triggers" the installation of all available archs (which is actually > coherent with the current behavior, but annoying nevertheless). > Example : If your package explicitly "Requires: curl" although it only > really requires libcurl.so.3, which rpm also added automatically, > you'll end up with curl.i386 and dragging in all of its dependencies. > Without the explicit requirement, only curl.x86_64 would have been > necessary. Those are packaging bugs regardless of how yum / rpm handle them. Explicit Requires should be avoided if the rpm will pick up library requirements on its own. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Thu Apr 12 19:59:54 2007 From: opensource at till.name (Till Maas) Date: Thu, 12 Apr 2007 21:59:54 +0200 Subject: [Fedora-packaging] Using of date in snapshot versions Message-ID: <200704122159.55518.opensource@till.name> Hiyas, the naming guidelines say that one should use the date do describe the snapshot: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-cfd71146dbb6f00cec9fe3623ea619f843394837 | If a snapshot package is considered a "pre-release package", you should | follow the guidelines listed in Pre-Release Packages, and use an %{alphatag} | in the following format: | YYYYMMDDcvs Maybe this is useful for cvs, because there is no better way to describe a snapshot. But e.g. with svn, which uses a global revision number, it is possible to use a unique id for the snapshot, where it is not uncertain which changes are included. For this reason I suggest to change the guideline, so that it suggests better identification strings for a snapshot, when it is avaiable, e.g. 123svn for a snapshot of an svn repository at revision 123. Regards, Till From tibbs at math.uh.edu Thu Apr 12 21:38:58 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Apr 2007 16:38:58 -0500 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704122159.55518.opensource@till.name> References: <200704122159.55518.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> For this reason I suggest to change the guideline, so that it TM> suggests better identification strings for a snapshot, when it is TM> avaiable, e.g. TM> 123svn TM> for a snapshot of an svn repository at revision 123. The date must still be in there. Some packages have used a format like 20070412svn1234, which is acceptable although not strictly listed in the naming guidelines as one of the possibilities. (Which is something that probably should be in the guidelines.) - J< From jkeating at redhat.com Thu Apr 12 21:58:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 17:58:03 -0400 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: References: <200704122159.55518.opensource@till.name> Message-ID: <200704121758.04105.jkeating@redhat.com> On Thursday 12 April 2007 17:38:58 Jason L Tibbitts III wrote: > The date must still be in there. ?Some packages have used a format > like 20070412svn1234, which is acceptable although not strictly listed > in the naming guidelines as one of the possibilities. ?(Which is > something that probably should be in the guidelines.) Well, since we have a 0.X. scheme, and X is always increasing, does it really matter if a date is in there, or that the numbers past X even increment the right way? 0.1.1234svn 0.2.1233svn 0.3.1334svn Wouldn't those work? I think the only thing we'd want to avoid is the gnarly git and hg sha sums as revisions. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Apr 12 22:25:42 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Apr 2007 17:25:42 -0500 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704121758.04105.jkeating@redhat.com> References: <200704122159.55518.opensource@till.name> <200704121758.04105.jkeating@redhat.com> Message-ID: <461EB1E6.2000800@math.unl.edu> Jesse Keating wrote: > On Thursday 12 April 2007 17:38:58 Jason L Tibbitts III wrote: >> The date must still be in there. Some packages have used a format >> like 20070412svn1234, which is acceptable although not strictly listed >> in the naming guidelines as one of the possibilities. (Which is >> something that probably should be in the guidelines.) > > Well, since we have a 0.X. scheme, and X is always increasing, does > it really matter if a date is in there, or that the numbers past X even > increment the right way? > > 0.1.1234svn > 0.2.1233svn > 0.3.1334svn > > Wouldn't those work? imo, yes. As you(Jessie) pointed out, as long as the X in 0.X increments, I don't really care what comes after it (within reason and sanity, of course). Unless there's some other reason for insisting on including the date, but I can't think of one atm. -- Rex From tibbs at math.uh.edu Fri Apr 13 00:58:01 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Apr 2007 19:58:01 -0500 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704121758.04105.jkeating@redhat.com> References: <200704122159.55518.opensource@till.name> <200704121758.04105.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Well, since we have a 0.X. scheme, and X is always JK> increasing, does it really matter if a date is in there, or that JK> the numbers past X even increment the right way? Well, I've had this exact discussion at least twice before and it's always come down to precisely the scheme I indicated. Feel free to take my place for this trip through that discussion. - J< From tibbs at math.uh.edu Fri Apr 13 01:05:14 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Apr 2007 20:05:14 -0500 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: References: <200704122159.55518.opensource@till.name> <200704121758.04105.jkeating@redhat.com> Message-ID: >>>>> "JLT" == Jason L Tibbitts writes: JLT> Well, I've had this exact discussion at least twice before and JLT> it's always come down to precisely the scheme I indicated. Some bits from my IRC logs: [Sat Aug 12 2006] [22:50:27] Hmmm, why do we mandate a date for the alphatag of an SVN checkout when the tree revision number actually makes more sense? [Sun Aug 13 2006] [02:13:27] tibbs: Michael Schwendt explained on the list at one point that the date is portable in case upstream migrates to a different revision control system whereas the revision number is only applicable as long as they keep using subversion. A proposal was made to use DATEsvnREV# if you wanted to include the rev# information and some people have used that (but I don't think it made it into the official guidelines.) [Sun Aug 13 2006] [09:13:14] abadger1999: I think that's rather pointless given that you'd just bump the number that comes before the alphatag. [Sun Aug 13 2006] [09:13:57] It's like arguing that they could switch from SVN to CVS one day, and worrying about the version going backwards because CVS < SVN. [Sun Aug 13 2006] [10:02:07] are svn revisions rpmsortable ? [Sun Aug 13 2006] [10:08:27] Do they need to be? [Sun Aug 13 2006] [10:08:56] You're supposed to bump the number before the alphatag anyway. So sortability of the alphatag shouldn't make a difference. [Sun Aug 13 2006] [10:09:33] In any case, they're a monotonically increasing integer. I don't know if that's rpmsortable. [Sun Aug 13 2006] [10:30:31] if they increase thats fine [Sun Aug 13 2006] [10:30:47] as long as it isn't something with checksums (mercerial) [Sun Aug 13 2006] [10:41:34] Even then I don't see the problem. It's a string which (supposedly) uniquely identifies the checkout. [Sun Aug 13 2006] [10:41:47] The number before the alphatag is what imposes the ordering. [Sun Aug 13 2006] [10:42:15] Using dates is ambiguous in any case; CVS just doesn't provide anything better unless you tag every commit. [Sun Aug 13 2006] [10:42:45] I don't see why something better couldn't be used for version control systems which provide it (which is pretty much everything except CVS). [Sun Aug 13 2006] [10:51:22] tibbs: think of cases were nothing changes but the snapshot number [Sun Aug 13 2006] [11:00:58] So you bump the number before the alphatag. I don't see the problem. [Sun Aug 13 2006] [11:01:39] The naming guidelines say that you have to do that every time the snapshot number changes. [Sun Aug 13 2006] [11:05:15] do they? [Sun Aug 13 2006] [11:05:32] I'm looking at the kismet example: [Sun Aug 13 2006] [11:05:34] kismet-1.0-4.20050515cvs (bugfix to the post-release cvs checkout) [Sun Aug 13 2006] [11:05:39] kismet-1.0-5.20050517cvs (new cvs checkout, note the increment of %{X}) [Sun Aug 13 2006] [11:05:48] Looks like an increment just because the snapshot changed. [Sun Aug 13 2006] [11:06:19] looks like they do yeah. [Sun Aug 13 2006] [11:06:23] The examples seem consistent in that. [Sun Aug 13 2006] [11:06:35] nod [Sun Aug 13 2006] [11:06:47] It looks like everything expects that the alphatag does not impose a strict ordering. [Sun Aug 13 2006] [11:06:58] I don't have really any objections, it'll just get fun if we special case each and every SCM possibility [Sun Aug 13 2006] [11:10:33] I'm not sure we'd need to. [Sun Aug 13 2006] [11:11:18] If the SCM in use provides an identifier which uniquely specifies a particular checkout, then use it. There should still be room for common sense. [Sun Aug 13 2006] [11:11:59] The real problem is that dates don't uniquely identify checkouts. [Sun Aug 13 2006] [11:12:52] But of course in some cases using dates may just be simpler. SVN is kind of special, I think, because it's the only one that provides a monotonically increasing serial number. [Sun Aug 13 2006] [11:13:04] oh boy, I can't wait to see the first package that has a mercerial sha1sum in the release string. [Sun Aug 13 2006] [11:13:21] Well, a date would be completely useless there in any case. [Sun Aug 13 2006] [11:14:00] nod. [Sun Aug 13 2006] [11:14:14] Nothing we have allows specification of things like branches anyway. [Sun Aug 13 2006] [11:15:08] So perhaps the point isn't that the date tells you what to check out. [Sun Aug 13 2006] [11:15:31] (I wasn't around for the original discussion. I can't imagine that this kind of thing wasn't covered already.) [Sun Aug 13 2006] [11:15:34] nod, more of when the snapshot was taken. [Sun Aug 13 2006] [11:15:46] i wasn't around either. [Sun Aug 13 2006] [11:16:15] Perhaps it's best to leave additional data like that for comments in the spec file. [Sun Aug 13 2006] [11:17:30] What's confusing is that the name of the SCM gets put in the alphatag, which makes it look like the date somehow refers to some kind of SCM identifier. [Sun Aug 13 2006] [11:18:00] yeah, it was probably not really discussed regarding the other SCMs [Sun Aug 13 2006] [11:19:46] It's not as if a particular package is going to have more than one upstream SCM. [Sun Aug 13 2006] [11:20:34] So what's the point of even including it? Just to indicate that it was pulled from the SCM instead of from some released snapshot? [Sun Aug 13 2006] [11:26:27] not sure [Sun Aug 13 2006] [11:26:32] best would be to ask spot [Sun Aug 13 2006] [12:57:08] tibbs: spot would be the only one to know all the reasoning behind the original naming. [Sun Aug 13 2006] [12:57:18] Here's mschwendt's post: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00447.html [Sun Aug 13 2006] [12:58:58] FWIW I agree that there's supposed to be an integer in the Release: before we get to this portion of the tag but you'll have to ask spot/mschwendt if there's something else going on. - J< From nicolas.mailhot at laposte.net Fri Apr 13 06:39:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Apr 2007 08:39:34 +0200 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <461EB1E6.2000800@math.unl.edu> References: <200704122159.55518.opensource@till.name> <200704121758.04105.jkeating@redhat.com> <461EB1E6.2000800@math.unl.edu> Message-ID: <1176446374.25161.6.camel@rousalka.dyndns.org> Le jeudi 12 avril 2007 ? 17:25 -0500, Rex Dieter a ?crit : > Unless there's some other reason for insisting on including the date, > but I can't think of one atm. It's nice to see at a glance when looking at at a srpm if it's a recent or stale snapshot. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From opensource at till.name Fri Apr 13 07:28:54 2007 From: opensource at till.name (Till Maas) Date: Fri, 13 Apr 2007 09:28:54 +0200 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: References: <200704122159.55518.opensource@till.name> Message-ID: <200704130929.03244.opensource@till.name> On Do April 12 2007, Jason L Tibbitts III wrote: > The date must still be in there. Some packages have used a format > like 20070412svn1234, which is acceptable although not strictly listed > in the naming guidelines as one of the possibilities. (Which is > something that probably should be in the guidelines.) I have a question about the date, in the guidelines it is written: | The date in reference is the date that the checkout was taken. So when I take a snapshot of revision 123 of a svn repository with the current revision 151 and the commit of revision 123 was a week ago, then the alphatag has to be: 20070413svn123? Imho it would make more sence to use the date of the commit of the revision. Also with respect to git/hg, it would make the checkout better identifiable when one would use: 20070413gitABCDEF with ABCDEF beeing the last six (or any other number of) characters of the sha1 hash of the revision. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Apr 13 12:58:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 08:58:58 -0400 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: References: <200704122159.55518.opensource@till.name> Message-ID: <200704130858.59117.jkeating@redhat.com> On Thursday 12 April 2007 21:05:14 Jason L Tibbitts III wrote: > JLT> Well, I've had this exact discussion at least twice before and > JLT> it's always come down to precisely the scheme I indicated. > > Some bits from my IRC logs: Seems we were in agreement with you here that something other than the date could be used. I think Michael is just being difficult here. The date really doesn't help because on Today I could check out a tag from 4 years ago and make it a snapshot. No more meaning full than an svn revision number, in fact, LESS meaning full. I'd fully support a draft to amend our guidelines around the snapshot stuff to be more flexible for things other than date. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Apr 13 13:00:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 09:00:35 -0400 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704130929.03244.opensource@till.name> References: <200704122159.55518.opensource@till.name> <200704130929.03244.opensource@till.name> Message-ID: <200704130900.35911.jkeating@redhat.com> On Friday 13 April 2007 03:28:54 Till Maas wrote: > I have a question about the date, in the guidelines it is written: > | The date in reference is the date that the checkout was taken. > > So when I take a snapshot of revision 123 of a svn repository with the > current revision 151 and the commit of revision 123 was a week ago, then > the alphatag has to be: > > 20070413svn123? > > Imho it would make more sence to use the date of the commit of the > revision. > > Also with respect to git/hg, it would make the checkout better identifiable > when one would use: > > 20070413gitABCDEF > > with ABCDEF beeing the last six (or any other number of) characters of the > sha1 hash of the revision. But the date of the checkin to who's branch, or is it the date of the checkin to the local person's clone, or the date after the clone was merged into the master repo or... I really think that Date here is arbitrary and half thought out. See my other post regarding a draft. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Fri Apr 13 16:29:53 2007 From: opensource at till.name (Till Maas) Date: Fri, 13 Apr 2007 18:29:53 +0200 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704130900.35911.jkeating@redhat.com> References: <200704122159.55518.opensource@till.name> <200704130929.03244.opensource@till.name> <200704130900.35911.jkeating@redhat.com> Message-ID: <200704131829.55107.opensource@till.name> On Fr April 13 2007, Jesse Keating wrote: > But the date of the checkin to who's branch, or is it the date of the > checkin to the local person's clone, or the date after the clone was merged > into the master repo or... I really think that Date here is arbitrary and > half thought out. See my other post regarding a draft. I suggest to use date when the revision became available at the url (location) that is described in the comment / script, which explains how to generate the snapshot tarball (See: http://fedoraproject.org/wiki/Packaging/SourceURL#head-615f6271efb394ab340a93a6cf030f2d08cf0d49). Regards, Till From a.badger at gmail.com Fri Apr 13 16:57:48 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Apr 2007 09:57:48 -0700 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704130929.03244.opensource@till.name> References: <200704122159.55518.opensource@till.name> <200704130929.03244.opensource@till.name> Message-ID: <1176483468.11234.16.camel@localhost.localdomain> On Fri, 2007-04-13 at 09:28 +0200, Till Maas wrote: > On Do April 12 2007, Jason L Tibbitts III wrote: > > > The date must still be in there. Some packages have used a format > > like 20070412svn1234, which is acceptable although not strictly listed > > in the naming guidelines as one of the possibilities. (Which is > > something that probably should be in the guidelines.) > > I have a question about the date, in the guidelines it is written: > | The date in reference is the date that the checkout was taken. > > So when I take a snapshot of revision 123 of a svn repository with the current > revision 151 and the commit of revision 123 was a week ago, then the alphatag > has to be: > > 20070413svn123? > > Imho it would make more sence to use the date of the commit of the revision. > > Also with respect to git/hg, it would make the checkout better identifiable > when one would use: > > 20070413gitABCDEF > > with ABCDEF beeing the last six (or any other number of) characters of the > sha1 hash of the revision. To be logical about date (I won't defend the use of date here, just if it is being used) you could checkout by date: svn co -r '{2007-04-13}' and then you can check which revid svn has given it with svn info if you want to include the revid as part of the release tag. Or we could amend the guidelines to say date of commit. The guidelines actually mean: date-which-I-can-tell-the-revision-control-system-so-I-can-get-the-same-checkout-you-did which is date of checkout when you checkout HEAD. -Toshio -------------- 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 ville.skytta at iki.fi Fri Apr 13 17:15:48 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 13 Apr 2007 20:15:48 +0300 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704130900.35911.jkeating@redhat.com> References: <200704122159.55518.opensource@till.name> <200704130929.03244.opensource@till.name> <200704130900.35911.jkeating@redhat.com> Message-ID: <200704132015.48775.ville.skytta@iki.fi> On Friday 13 April 2007, Jesse Keating wrote: > > But the date of the checkin to who's branch, or is it the date of the > checkin to the local person's clone, or the date after the clone was merged > into the master repo or... The release tag is not the place to even try to embed that info into. We want the exact commands how the snapshot was generated properly documented anyway. http://fedoraproject.org/wiki/PackagingDrafts/SourceUrl From Axel.Thimm at ATrpms.net Fri Apr 13 17:20:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 13 Apr 2007 19:20:42 +0200 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <200704122159.55518.opensource@till.name> References: <200704122159.55518.opensource@till.name> Message-ID: <20070413172042.GE32753@neu.nirvana> Hi, On Thu, Apr 12, 2007 at 09:59:54PM +0200, Till Maas wrote: > | If a snapshot package is considered a "pre-release package", you should > | follow the guidelines listed in Pre-Release Packages, and use an %{alphatag} > | in the following format: > | YYYYMMDDcvs > > Maybe this is useful for cvs, because there is no better way to describe a > snapshot. But e.g. with svn, which uses a global revision number, it is > possible to use a unique id for the snapshot, where it is not uncertain which > changes are included. Well, you are correct, just keep two things in mind: a) the guideline above is a "should" guideline, which means no enforcement. So any sensible scheme is OK with the guidelines. b) The idea is to avoid packaging snapshots. Of course there are projects that never release and still have a very good codebase that is worth packaging. But instead of putting energy into how to deal with unreleased software, maybe it's better to invest in persuading or helping the upstream project to stamp off a release. FWIW if you're going to package svn sheckout the more or less canonical "snapshot" tag is r, e.g. prepend a lower "r" in front of the revision. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Fri Apr 13 17:21:48 2007 From: opensource at till.name (Till Maas) Date: Fri, 13 Apr 2007 19:21:48 +0200 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <1176483468.11234.16.camel@localhost.localdomain> References: <200704122159.55518.opensource@till.name> <200704130929.03244.opensource@till.name> <1176483468.11234.16.camel@localhost.localdomain> Message-ID: <200704131921.49087.opensource@till.name> On Fr April 13 2007, Toshio Kuratomi wrote: > To be logical about date (I won't defend the use of date here, just if > it is being used) you could checkout by date: > svn co -r '{2007-04-13}' This only works for dates that have already passed. It seems to me, that svn co -r '{2007-04-13}' will include any changesets up to 2007-04-13 00:00 (don't know which timezone, I guess the servers one). So when I want to include a changeset that happend later on 2007-04-13, I have to use svn co -r '{2007-04-14}' which will include all changesets up to now, but when invoked a day latey, it may include also other changesets. This is a problem I encountered yesterday, because I needed a recent revision, which contains a security fix. > date-which-I-can-tell-the-revision-control-system-so-I-can-get-the-same-che >ckout-you-did > > which is date of checkout when you checkout HEAD. When is this meant, than in case of svn the revision would be a better substitution, when the date is today. Regards, Till From a.badger at gmail.com Fri Apr 13 20:58:59 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Apr 2007 13:58:59 -0700 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <200704130858.59117.jkeating@redhat.com> References: <200704122159.55518.opensource@till.name> <200704130858.59117.jkeating@redhat.com> Message-ID: <1176497939.11234.119.camel@localhost.localdomain> On Fri, 2007-04-13 at 08:58 -0400, Jesse Keating wrote: > On Thursday 12 April 2007 21:05:14 Jason L Tibbitts III wrote: > > JLT> Well, I've had this exact discussion at least twice before and > > JLT> it's always come down to precisely the scheme I indicated. > > > > Some bits from my IRC logs: > > Seems we were in agreement with you here that something other than the date > could be used. > I agree. > I think Michael is just being difficult here. The date really doesn't help > because on Today I could check out a tag from 4 years ago and make it a > snapshot. No more meaning full than an svn revision number, in fact, LESS > meaning full. > Well... only because our guidelines are poorly expressing the use of date. They assume that the snapshot is being taken on HEAD. A minor revision that makes date meaningful in this context would be "When using snapshots, use the date that can be used to checkout the tree you are using from the VCS." > I'd fully support a draft to amend our guidelines around the snapshot stuff to > be more flexible for things other than date. > I would as well. Here are some things to consider: Goals: * Ability to reproduce the snapshot by checking it out from the upstream VCS. - Note that the primary place that this should be documented is not in the release tag but in a comment in the spec file. * Ability for end users to tell how recent the snapshot is. * Ability for end users to compare the version they have against other available versions. To me, the release tag after the rpmsortable integer is mostly for the end-user's benefit. So the latter two goals have more weight for me than the first. Issues and Non-Issues: * The tag does not need to be rpmsortable as there should be an integer in the release tag that takes precedence over this. * Each VCS has different ids. (Note, I'm ignoring tags as that's not something we can control for making snapshots of upstream projects.) - cvs only has dates for whole-tree checkouts. - svn has dates and revision numbers - git has hashes and dates and ?? - hg has revision numbers, (hash|revision id)(Not sure which) and dates and ?? - bzr has revision numbers, revision ids, and dates. * Distributed VCS's start to take us into realms in addition to naming. For instance, upstream may have a canonical stable branch/repo and a canonical development branch/repo. A snapshot taken from either branch could be represented by the same date or revision number (ie: they are meaningless without also specifying the branch/repo they come from). They would have different revids/hashes. Thoughts: Hashes and revisionids don't give very good information to the end user. Which is a newer snapshot: fa554dc or 65aad91? Revision numbers (a monotonically incrementing number) and dates seem to have about the same benefits and drawbacks to me. Dates are nice when used with HEAD checkouts because they tell the end user when an snapshot was taken at a glance. The packager has to work harder to get this benefit with historical checkouts (Figure out which date they want to grab from). Revision numbers and distributed VCS's could be slightly confusing to the end user as a revision number, although monotonically increasing on a particular branch, could go backwards if the package was rebased against a different tree but hopefully that wouldn't happen very often. I wouldn't be opposed to seeing revision numbers and/or dates used but revisionids and hashes should be banned. The canonical method of getting the snapshot should always be included in the spec file. Maybe something like this for prereleases: foo-1.0-0.2.20061005cvs bar-1.0-0.2.512svn baz-1.0-0.3.123bzr spam-1.0-0.3.171hg ham-1.0-0.4.20070121git -Toshio -------------- 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 a.badger at gmail.com Fri Apr 13 21:57:25 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Apr 2007 14:57:25 -0700 Subject: [Fedora-packaging] UTF-8 Encoding update Message-ID: <1176501445.11234.142.camel@localhost.localdomain> Hey, After some correspondence with Nicolas Mailhot on -maintainers, we arrived at some updated wording for UTF-8 (Encoding and Filename). Do we need to approve the wording changes? If so it would be nice to vote on list as I don't think there's any changes to the spirit of the guideline, just clarifications in language:: == Encoding == Unless you need to use characters outside the [http://commons.wikimedia.org/wiki/Image:Ascii_full.png ASCII repertoire], you will not need to be concerned about the encoding of the spec file. If you do need non-ASCII characters, save your spec files as UTF-8. If you're in doubt as to what characters are ASCII, please refer to [http://commons.wikimedia.org/wiki/Image:Ascii_full.png this chart]. === Non-ASCII Filenames === Similarly, filenames that contain non-ASCII characters must be encoded as UTF-8. Since there's no way to note which encoding the filename is in, using the same encoding for all filenames is the best way to ensure users can read the filenames properly. If upstream ships filenames that are not encoded in UTF-8 you can use a utility like convmv (from the convmv package) to convert the filename in your %install section. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Apr 13 22:01:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 18:01:31 -0400 Subject: [Fedora-packaging] UTF-8 Encoding update In-Reply-To: <1176501445.11234.142.camel@localhost.localdomain> References: <1176501445.11234.142.camel@localhost.localdomain> Message-ID: <200704131801.32001.jkeating@redhat.com> On Friday 13 April 2007 17:57:25 Toshio Kuratomi wrote: > After some correspondence with Nicolas Mailhot on -maintainers, we > arrived at some updated wording for UTF-8 (Encoding and Filename). ?Do > we need to approve the wording changes? ?If so it would be nice to vote > on list as I don't think there's any changes to the spirit of the > guideline, just clarifications in language:: +1 -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Sat Apr 14 03:34:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 13 Apr 2007 22:34:34 -0500 Subject: [Fedora-packaging] UTF-8 Encoding update In-Reply-To: <200704131801.32001.jkeating@redhat.com> References: <1176501445.11234.142.camel@localhost.localdomain> <200704131801.32001.jkeating@redhat.com> Message-ID: <1176521674.3970.224.camel@localhost.localdomain> On Fri, 2007-04-13 at 18:01 -0400, Jesse Keating wrote: > On Friday 13 April 2007 17:57:25 Toshio Kuratomi wrote: > > After some correspondence with Nicolas Mailhot on -maintainers, we > > arrived at some updated wording for UTF-8 (Encoding and Filename). Do > > we need to approve the wording changes? If so it would be nice to vote > > on list as I don't think there's any changes to the spirit of the > > guideline, just clarifications in language:: > > +1 +1 From tcallawa at redhat.com Sat Apr 14 03:43:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 13 Apr 2007 22:43:02 -0500 Subject: [Fedora-packaging] Using of date in snapshot versions In-Reply-To: <1176497939.11234.119.camel@localhost.localdomain> References: <200704122159.55518.opensource@till.name> <200704130858.59117.jkeating@redhat.com> <1176497939.11234.119.camel@localhost.localdomain> Message-ID: <1176522182.3970.234.camel@localhost.localdomain> On Fri, 2007-04-13 at 13:58 -0700, Toshio Kuratomi wrote: > foo-1.0-0.2.20061005cvs > bar-1.0-0.2.512svn > baz-1.0-0.3.123bzr > spam-1.0-0.3.171hg > ham-1.0-0.4.20070121git My thoughts on this are pretty simple: All checkout packages are either pre or post: Pre: %{name}-%{version}-0.1.%{alphatag} Post: %{name}-%{version}-1.%{alphatag} %{alphatag} contains either the revision integer or the date of the checkout, followed by the revision type id: RCS ID Format ===== ==== ======== CVS cvs date Subversion svn revision int Bazaar bzr revision int Git git date Mercurial hg revision int If the Revision Control System uses simple, integer revisions, use that. If not, use the date of checkout. Revisionids and hashes are not permitted. ~spot From ville.skytta at iki.fi Sat Apr 14 08:54:08 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 14 Apr 2007 11:54:08 +0300 Subject: [Fedora-packaging] UTF-8 Encoding update In-Reply-To: <1176501445.11234.142.camel@localhost.localdomain> References: <1176501445.11234.142.camel@localhost.localdomain> Message-ID: <200704141154.08402.ville.skytta@iki.fi> On Saturday 14 April 2007, Toshio Kuratomi wrote: > Hey, > > After some correspondence with Nicolas Mailhot on -maintainers, we > arrived at some updated wording for UTF-8 (Encoding and Filename). Do > we need to approve the wording changes? If so it would be nice to vote > on list as I don't think there's any changes to the spirit of the > guideline, just clarifications in language:: +1, although linking twice to the same image is a bit redundant in the "Encoding" chapter and the first one could be dropped. From Axel.Thimm at ATrpms.net Sat Apr 14 09:24:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 11:24:24 +0200 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <1176522182.3970.234.camel@localhost.localdomain> References: <200704122159.55518.opensource@till.name> <200704130858.59117.jkeating@redhat.com> <1176497939.11234.119.camel@localhost.localdomain> <1176522182.3970.234.camel@localhost.localdomain> Message-ID: <20070414092424.GT25962@neu.nirvana> On Fri, Apr 13, 2007 at 10:43:02PM -0500, Tom spot Callaway wrote: > On Fri, 2007-04-13 at 13:58 -0700, Toshio Kuratomi wrote: > > foo-1.0-0.2.20061005cvs > > bar-1.0-0.2.512svn > > baz-1.0-0.3.123bzr > > spam-1.0-0.3.171hg > > ham-1.0-0.4.20070121git > %{alphatag} contains either the revision integer or the date of the > checkout, followed by the revision type id: The convention is reversed, e.g. people say cvs20061005 and svn512. This doesn't change any ordering logig, is easier to read (the suffixing style merges the vcs id with the actual build ids, prefixing brings a eye-natural separator), and starting with a non-integer saves the day from funny ordering bug like the following: foo-1.0-0.2.20061005cvs A trivial rebuild (like a braindead EPEL mass rebuild with a mass .1 forking): foo-1.0-0.2.1.20061005cvs < foo-1.0-0.2.20061005cvs So instead of introducing major.%{alphatag}.minor braindamage to deal with the latter, let's make it even mandatory to start %{alphatag} with an `alpha' and you're set. And we're also following common conventions in naming snapshots and cvs checkouts. BTW this is the reason why disttags also have to always start with a letter. At the beginning of Fedora Core there were disttags examined like "0.7.3", "0.8.0", "0.9", "1", "2", but they would fail in the same way as the example above, so they would have to get "fc" prepended, and having RHL9 carrying a disttag of "fc0.9" looked a bit awkward, so it never made it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Apr 14 09:14:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Apr 2007 11:14:01 +0200 Subject: [Fedora-packaging] Re: UTF-8 Encoding update In-Reply-To: <1176521674.3970.224.camel@localhost.localdomain> References: <1176501445.11234.142.camel@localhost.localdomain> <200704131801.32001.jkeating@redhat.com> <1176521674.3970.224.camel@localhost.localdomain> Message-ID: <20070414091401.GS25962@neu.nirvana> On Fri, Apr 13, 2007 at 10:34:34PM -0500, Tom spot Callaway wrote: > On Fri, 2007-04-13 at 18:01 -0400, Jesse Keating wrote: > > On Friday 13 April 2007 17:57:25 Toshio Kuratomi wrote: > > > After some correspondence with Nicolas Mailhot on -maintainers, we > > > arrived at some updated wording for UTF-8 (Encoding and Filename). Do > > > we need to approve the wording changes? If so it would be nice to vote > > > on list as I don't think there's any changes to the spirit of the > > > guideline, just clarifications in language:: assuming: Toshio: +1 > > +1 > +1 +1 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Apr 14 11:13:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Apr 2007 07:13:20 -0400 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <20070414092424.GT25962@neu.nirvana> References: <200704122159.55518.opensource@till.name> <1176522182.3970.234.camel@localhost.localdomain> <20070414092424.GT25962@neu.nirvana> Message-ID: <200704140713.21129.jkeating@redhat.com> On Saturday 14 April 2007 05:24:24 Axel Thimm wrote: > The convention is reversed, e.g. people say cvs20061005 and > svn512. This doesn't change any ordering logig, is easier to read (the > suffixing style merges the vcs id with the actual build ids, prefixing > brings a eye-natural separator), I wouldn't mind this method either, although I'm ignoring the flamebait in the rest of this mail. The above was enough. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dev at nigelj.com Sun Apr 15 11:53:07 2007 From: dev at nigelj.com (Nigel Jones) Date: Sun, 15 Apr 2007 23:53:07 +1200 Subject: [Fedora-packaging] Issues with Ocaml and Static Linking In-Reply-To: <461D9A62.2070006@nigelj.com> References: <461D9A62.2070006@nigelj.com> Message-ID: <46221223.7040805@nigelj.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel Jones wrote: > Hi everyone, > > While putting in a couple of packages for Extras Review I've stumbled > into a couple of issues regarding how Ocaml links libraries and how the > Fedora Packaging Guidelines are set. > > My packages in question are: > ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) > camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) > freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815) > > Basically, ocamlSDL and camlimages produce two sets of libraries (a set > of dynamic libraries, and another set for development etc), sadly when > other packages like freetennis build, they staticly link to libraries > such as camlimages/ocamlSDL. > > I found it semi-suspect when I built freetennis, and hence why I asked > on bugzilla when I posted the three packages for review, however I did > some more questioning today and after a quick IRC discussion in #ocaml > was told: > > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries > right? > 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. > 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. > 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for > dynamic loading as static loading. > > Looking at my installed files on my laptop, lablgl, lablgtk and labltk > (as well as the main ocaml package) store .a, .cma and .cmxa files in > /usr/lib/ocaml (and subfolders). > > As I'm only new to Fedora packaging, could someone please advise on > where I should from here on the matter and what the position of FESCO is > on Ocaml static libraries, and where I should go from here. > > Thanks, > > Nigel Jones I'm just wondering if anyone has any thoughts on this issue. I've talked to some more people in #ocaml (Freenode), who suggested that I try a patch by the name of 'scaml' which is a year or two old (and although can be manually applied to the ocaml source, it does not work (problems with assembly which I've not comfortable meddling with). We'd actually need to downgrade to 3.07 which was removed from Fedora in Feb 05 to get the patch working to satisfy the need for dynamic loading which I'm sure would upset a few people. Upstream already have a bug opened stating that they need to fix the issue but they have never updated it, or assigned it to anyone. So my main question is "where to from here?" Thanks, Nigel Jones - -- Fedora-packaging mailing list Fedora-packaging at redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGIhIjpldg9bRmG6kRAmNWAJ9J9Is75ecQOMoxvJgMtkrahJr76wCfVmEo ut46/8ZGBkzCJCrRHyywwTQ= =6wVo -----END PGP SIGNATURE----- From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 16 09:54:15 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 16 Apr 2007 11:54:15 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070406182240.GD2318@neu.nirvana> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> <200704061406.53019.jkeating@redhat.com> <20070406182240.GD2318@neu.nirvana> Message-ID: <20070416115415.4cba2090@python3.es.egwn.lan> Axel Thimm wrote : > On Fri, Apr 06, 2007 at 02:06:52PM -0400, Jesse Keating wrote: > > On Friday 06 April 2007 13:52:12 Orion Poplawski wrote: > > > I would recommend at least one rebuild of a package just before release > > > though for everything but pure data packages. ?I've been surprised by > > > what has changed and caused failures. > > > > Continuous rebuilds are done, just not imported. I think this is great, we > > get the benefit without the churn. Churning the entire package set without > > reason is ridiculous and may do more harm than good. See Matt D's > > core/extras rebuild reports. > > But nobody tests them. Only fatal build errors are probed that way. IIRC this is not true : A rebuild is also considered "failed" if it creates packages with different requires or provides than the ones from the packages in the repository. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2943.fc6 Load : 0.70 0.67 1.01 From Axel.Thimm at ATrpms.net Mon Apr 16 10:26:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 16 Apr 2007 12:26:45 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070416115415.4cba2090@python3.es.egwn.lan> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> <200704061406.53019.jkeating@redhat.com> <20070406182240.GD2318@neu.nirvana> <20070416115415.4cba2090@python3.es.egwn.lan> Message-ID: <20070416102645.GB16909@neu.nirvana> On Mon, Apr 16, 2007 at 11:54:15AM +0200, Matthias Saou wrote: > Axel Thimm wrote : > > > On Fri, Apr 06, 2007 at 02:06:52PM -0400, Jesse Keating wrote: > > > On Friday 06 April 2007 13:52:12 Orion Poplawski wrote: > > > > I would recommend at least one rebuild of a package just before release > > > > though for everything but pure data packages. ?I've been surprised by > > > > what has changed and caused failures. > > > > > > Continuous rebuilds are done, just not imported. I think this is great, we > > > get the benefit without the churn. Churning the entire package set without > > > reason is ridiculous and may do more harm than good. See Matt D's > > > core/extras rebuild reports. > > > > But nobody tests them. Only fatal build errors are probed that way. > > IIRC this is not true : A rebuild is also considered "failed" if it > creates packages with different requires or provides than the ones from > the packages in the repository. So, if the build generates the same sonames, it is already considered run-time tested? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Apr 16 10:38:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 16 Apr 2007 12:38:57 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070416115415.4cba2090@python3.es.egwn.lan> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> <200704061406.53019.jkeating@redhat.com> <20070406182240.GD2318@neu.nirvana> <20070416115415.4cba2090@python3.es.egwn.lan> Message-ID: <46235241.5070406@leemhuis.info> On 16.04.2007 11:54, Matthias Saou wrote: > > IIRC this is not true : A rebuild is also considered "failed" if it > creates packages with different requires or provides than the ones from > the packages in the repository. > That would be news to me. I'm not aware of any such checks in the Extras buildsys, and none of my packages ever stumbled over such checks -- which I'd say would be likely. CU thl From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 16 11:04:09 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 16 Apr 2007 13:04:09 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <46235241.5070406@leemhuis.info> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> <200704061406.53019.jkeating@redhat.com> <20070406182240.GD2318@neu.nirvana> <20070416115415.4cba2090@python3.es.egwn.lan> <46235241.5070406@leemhuis.info> Message-ID: <20070416130409.44f83f8b@python3.es.egwn.lan> Thorsten Leemhuis wrote : > On 16.04.2007 11:54, Matthias Saou wrote: > > > > IIRC this is not true : A rebuild is also considered "failed" if it > > creates packages with different requires or provides than the ones from > > the packages in the repository. > > > > That would be news to me. I'm not aware of any such checks in the Extras > buildsys, and none of my packages ever stumbled over such checks -- > which I'd say would be likely. I'm not referring to the buildsys, but to Matt Domsch's automated rebuilds and reports. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2943.fc6 Load : 1.20 1.25 0.94 From fedora at leemhuis.info Mon Apr 16 11:18:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 16 Apr 2007 13:18:44 +0200 Subject: [Fedora-packaging] Re: Statistics on usage of disttags in Fedora Core and Extras In-Reply-To: <20070416130409.44f83f8b@python3.es.egwn.lan> References: <20070406160456.GB2318@neu.nirvana> <46167F95.5060707@leemhuis.info> <461688CC.70509@cora.nwra.com> <200704061406.53019.jkeating@redhat.com> <20070406182240.GD2318@neu.nirvana> <20070416115415.4cba2090@python3.es.egwn.lan> <46235241.5070406@leemhuis.info> <20070416130409.44f83f8b@python3.es.egwn.lan> Message-ID: <46235B94.6040307@leemhuis.info> On 16.04.2007 13:04, Matthias Saou wrote: > Thorsten Leemhuis wrote : >> On 16.04.2007 11:54, Matthias Saou wrote: >>> IIRC this is not true : A rebuild is also considered "failed" if it >>> creates packages with different requires or provides than the ones from >>> the packages in the repository. >> That would be news to me. I'm not aware of any such checks in the Extras >> buildsys, and none of my packages ever stumbled over such checks -- >> which I'd say would be likely. > I'm not referring to the buildsys, but to Matt Domsch's automated > rebuilds and reports. Ohh, sorry, that wasn't obvious to me in that context. /me should have looked closer CU thl From a.badger at gmail.com Thu Apr 19 03:56:42 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 18 Apr 2007 20:56:42 -0700 Subject: [Fedora-packaging] Issues with Ocaml and Static Linking In-Reply-To: <46221223.7040805@nigelj.com> References: <461D9A62.2070006@nigelj.com> <46221223.7040805@nigelj.com> Message-ID: <1176955002.25462.108.camel@localhost.localdomain> On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nigel Jones wrote: > > Hi everyone, > > > > While putting in a couple of packages for Extras Review I've stumbled > > into a couple of issues regarding how Ocaml links libraries and how the > > Fedora Packaging Guidelines are set. > > > > My packages in question are: > > ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) > > camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) > > freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815) > > > > Basically, ocamlSDL and camlimages produce two sets of libraries (a set > > of dynamic libraries, and another set for development etc), sadly when > > other packages like freetennis build, they staticly link to libraries > > such as camlimages/ocamlSDL. > > > > I found it semi-suspect when I built freetennis, and hence why I asked > > on bugzilla when I posted the three packages for review, however I did > > some more questioning today and after a quick IRC discussion in #ocaml > > was told: > > > > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries > > right? > > 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. > > 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. > > 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for > > dynamic loading as static loading. > > > > Looking at my installed files on my laptop, lablgl, lablgtk and labltk > > (as well as the main ocaml package) store .a, .cma and .cmxa files in > > /usr/lib/ocaml (and subfolders). > > > > As I'm only new to Fedora packaging, could someone please advise on > > where I should from here on the matter and what the position of FESCO is > > on Ocaml static libraries, and where I should go from here. > > > > Thanks, > > > > Nigel Jones > > I'm just wondering if anyone has any thoughts on this issue. > > I've talked to some more people in #ocaml (Freenode), who suggested that > I try a patch by the name of 'scaml' which is a year or two old (and > although can be manually applied to the ocaml source, it does not work > (problems with assembly which I've not comfortable meddling with). > > We'd actually need to downgrade to 3.07 which was removed from Fedora in > Feb 05 to get the patch working to satisfy the need for dynamic loading > which I'm sure would upset a few people. > > Upstream already have a bug opened stating that they need to fix the > issue but they have never updated it, or assigned it to anyone. > > So my main question is "where to from here?" I think, if the ocaml compiler doesn't support dynamic libraries, static linking would be acceptable. This doesn't mean that we shouldn't press upstream to add dynamic linking (and convert all our packages when that becomes available) just an acknowledgment that fixing the limitation has to be done upstream (it could be done by someone within Fedora but the fix needs to go upstream). This is similar to allowing C libraries in even if they only build statically. If I'm not understanding precisely what the limitation is, feel free to clarify. -Toshio -------------- 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 dev at nigelj.com Thu Apr 19 06:33:23 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 19 Apr 2007 18:33:23 +1200 Subject: [Fedora-packaging] Issues with Ocaml and Static Linking In-Reply-To: <1176955002.25462.108.camel@localhost.localdomain> References: <461D9A62.2070006@nigelj.com> <46221223.7040805@nigelj.com> <1176955002.25462.108.camel@localhost.localdomain> Message-ID: <46270D33.6070800@nigelj.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toshio Kuratomi wrote: > On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Nigel Jones wrote: >>> Hi everyone, >>> >>> While putting in a couple of packages for Extras Review I've stumbled >>> into a couple of issues regarding how Ocaml links libraries and how the >>> Fedora Packaging Guidelines are set. >>> >>> My packages in question are: >>> ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) >>> camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) >>> freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815) >>> >>> Basically, ocamlSDL and camlimages produce two sets of libraries (a set >>> of dynamic libraries, and another set for development etc), sadly when >>> other packages like freetennis build, they staticly link to libraries >>> such as camlimages/ocamlSDL. >>> >>> I found it semi-suspect when I built freetennis, and hence why I asked >>> on bugzilla when I posted the three packages for review, however I did >>> some more questioning today and after a quick IRC discussion in #ocaml >>> was told: >>> >>> 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries >>> right? >>> 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. >>> 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. >>> 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for >>> dynamic loading as static loading. >>> >>> Looking at my installed files on my laptop, lablgl, lablgtk and labltk >>> (as well as the main ocaml package) store .a, .cma and .cmxa files in >>> /usr/lib/ocaml (and subfolders). >>> >>> As I'm only new to Fedora packaging, could someone please advise on >>> where I should from here on the matter and what the position of FESCO is >>> on Ocaml static libraries, and where I should go from here. >>> >>> Thanks, >>> >>> Nigel Jones >> I'm just wondering if anyone has any thoughts on this issue. >> >> I've talked to some more people in #ocaml (Freenode), who suggested that >> I try a patch by the name of 'scaml' which is a year or two old (and >> although can be manually applied to the ocaml source, it does not work >> (problems with assembly which I've not comfortable meddling with). >> >> We'd actually need to downgrade to 3.07 which was removed from Fedora in >> Feb 05 to get the patch working to satisfy the need for dynamic loading >> which I'm sure would upset a few people. >> >> Upstream already have a bug opened stating that they need to fix the >> issue but they have never updated it, or assigned it to anyone. >> >> So my main question is "where to from here?" > > I think, if the ocaml compiler doesn't support dynamic libraries, static > linking would be acceptable. This doesn't mean that we shouldn't press Okay, so my packages which sadly use static linking (because of the design problem in ocaml) should be okay for now, and I can resume trying to find sponsorship so I can include them? > upstream to add dynamic linking (and convert all our packages when that > becomes available) just an acknowledgment that fixing the limitation has > to be done upstream (it could be done by someone within Fedora but the > fix needs to go upstream). I totally agree, I added a bug to Ocaml (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236497) about the problem, but my impression so far from the maintainer is "it's their problem not ours". > > This is similar to allowing C libraries in even if they only build > statically. I've never known this to be the case, but I'll take your word on it ;) > > If I'm not understanding precisely what the limitation is, feel free to > clarify. It seems that in some 'special' cases dynamic linking is possible, but it generally isn't, instead during build, it will staticly link cmxa files into the output. I'm still not 100% certain myself to be honest, but I've been told, it's a LOT of legwork (and pain) to dynamically include libraries. > > -Toshio > > > ------------------------------------------------------------------------ > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging Thanks, Nigel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGJwzGpldg9bRmG6kRAnH5AJ4lIcwQPy4pPie9LKGptyGsGPozxgCfQ1zD 5gQRof2ZccIfm4lTFbiIt1w= =pOYE -----END PGP SIGNATURE----- From fnasser at redhat.com Thu Apr 19 18:16:29 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 19 Apr 2007 14:16:29 -0400 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <20070413172042.GE32753@neu.nirvana> References: <200704122159.55518.opensource@till.name> <20070413172042.GE32753@neu.nirvana> Message-ID: <4627B1FD.2050509@redhat.com> Axel Thimm wrote: > (...) > > FWIW if you're going to package svn sheckout the more or less > canonical "snapshot" tag is r, e.g. prepend a lower "r" in > front of the revision. > > And a capital D for dates? Fernando From Axel.Thimm at ATrpms.net Thu Apr 19 18:31:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 19 Apr 2007 20:31:29 +0200 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <4627B1FD.2050509@redhat.com> References: <200704122159.55518.opensource@till.name> <20070413172042.GE32753@neu.nirvana> <4627B1FD.2050509@redhat.com> Message-ID: <20070419183129.GE13273@neu.nirvana> On Thu, Apr 19, 2007 at 02:16:29PM -0400, Fernando Nasser wrote: > Axel Thimm wrote: > >FWIW if you're going to package svn sheckout the more or less > >canonical "snapshot" tag is r, e.g. prepend a lower "r" in > >front of the revision. > And a capital D for dates? Is that a serious question, or is there a simley missing? :) If it's serious: I suspect everyone can identify that something matching 2006XXXX or 2007XXXX implies a date, and if not a capital D won't help either. If the similey was missing: Yes a capital D would be fine, but you should use the proper locale, not everywhere does a date translate to something that actually starts with a "d", at least in Greek it starts with an eta. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fnasser at redhat.com Thu Apr 19 19:27:35 2007 From: fnasser at redhat.com (Fernando Nasser) Date: Thu, 19 Apr 2007 15:27:35 -0400 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <20070419183129.GE13273@neu.nirvana> References: <200704122159.55518.opensource@till.name> <20070413172042.GE32753@neu.nirvana> <4627B1FD.2050509@redhat.com> <20070419183129.GE13273@neu.nirvana> Message-ID: <4627C2A7.3010804@redhat.com> Axel Thimm wrote: > On Thu, Apr 19, 2007 at 02:16:29PM -0400, Fernando Nasser wrote: > >> Axel Thimm wrote: >> >>> FWIW if you're going to package svn sheckout the more or less >>> canonical "snapshot" tag is r, e.g. prepend a lower "r" in >>> front of the revision. >>> > > >> And a capital D for dates? >> > > Is that a serious question, or is there a simley missing? :) > > Yes, I thought it was obvious :-) > If it's serious: I suspect everyone can identify that something > matching 2006XXXX or 2007XXXX implies a date, and if not a capital D > won't help either. > > If the similey was missing: Yes a capital D would be fine, but you > should use the proper locale, not everywhere does a date translate to > something that actually starts with a "d", at least in Greek it starts > with an eta. ;) > I always add comments before the Source0: telling how to obtain the sources if it cannot be done directly with a URL on the Source0: specification. Cheers, Fernando From opensource at till.name Thu Apr 19 19:35:20 2007 From: opensource at till.name (Till Maas) Date: Thu, 19 Apr 2007 21:35:20 +0200 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <20070419183129.GE13273@neu.nirvana> References: <200704122159.55518.opensource@till.name> <4627B1FD.2050509@redhat.com> <20070419183129.GE13273@neu.nirvana> Message-ID: <200704192135.22086.opensource@till.name> On Do April 19 2007, Axel Thimm wrote: > If it's serious: I suspect everyone can identify that something > matching 2006XXXX or 2007XXXX implies a date, and if not a capital D > won't help either. I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform afaik. Would this cause any problems with rpm? Regards, Till From a.badger at gmail.com Thu Apr 19 19:51:46 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 19 Apr 2007 12:51:46 -0700 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <200704192135.22086.opensource@till.name> References: <200704122159.55518.opensource@till.name> <4627B1FD.2050509@redhat.com> <20070419183129.GE13273@neu.nirvana> <200704192135.22086.opensource@till.name> Message-ID: <1177012306.25462.165.camel@localhost.localdomain> On Thu, 2007-04-19 at 21:35 +0200, Till Maas wrote: > On Do April 19 2007, Axel Thimm wrote: > > > If it's serious: I suspect everyone can identify that something > > matching 2006XXXX or 2007XXXX implies a date, and if not a capital D > > won't help either. > > I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform > afaik. Would this cause any problems with rpm? > If not with rpm, there's a good chance it will cause problems for people's local scripts because of dash's being used as separators for name-version-release. -Toshio -------------- 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 ville.skytta at iki.fi Thu Apr 19 19:53:19 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 19 Apr 2007 22:53:19 +0300 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <1177012306.25462.165.camel@localhost.localdomain> References: <200704122159.55518.opensource@till.name> <200704192135.22086.opensource@till.name> <1177012306.25462.165.camel@localhost.localdomain> Message-ID: <200704192253.19515.ville.skytta@iki.fi> On Thursday 19 April 2007, Toshio Kuratomi wrote: > On Thu, 2007-04-19 at 21:35 +0200, Till Maas wrote: > > On Do April 19 2007, Axel Thimm wrote: > > > If it's serious: I suspect everyone can identify that something > > > matching 2006XXXX or 2007XXXX implies a date, and if not a capital D > > > won't help either. > > > > I would prefer to use YYYY-MM-DD which is easier to read and an ISO > > conform afaik. Would this cause any problems with rpm? > > If not with rpm, there's a good chance it will cause problems for > people's local scripts because of dash's being used as separators for > name-version-release. rpmbuild refuses to build a package with dashes in Version or Release. From nicolas.mailhot at laposte.net Thu Apr 19 20:44:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 19 Apr 2007 22:44:27 +0200 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <200704192135.22086.opensource@till.name> References: <200704122159.55518.opensource@till.name> <4627B1FD.2050509@redhat.com> <20070419183129.GE13273@neu.nirvana> <200704192135.22086.opensource@till.name> Message-ID: <1177015467.29179.18.camel@rousalka.dyndns.org> Le jeudi 19 avril 2007 ? 21:35 +0200, Till Maas a ?crit : > On Do April 19 2007, Axel Thimm wrote: > > > If it's serious: I suspect everyone can identify that something > > matching 2006XXXX or 2007XXXX implies a date, and if not a capital D > > won't help either. > > I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform > afaik. Would this cause any problems with rpm? IIRC the condensed form is legit too, even if it's far less readable. Since - is the rpm separator using YYYY-MM-DD may cause problems. Though it would be worth some testing before assuming it won't work. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Thu Apr 19 20:48:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 19 Apr 2007 22:48:49 +0200 Subject: [Fedora-packaging] Re: Using of date in snapshot versions In-Reply-To: <200704192135.22086.opensource@till.name> References: <200704122159.55518.opensource@till.name> <4627B1FD.2050509@redhat.com> <20070419183129.GE13273@neu.nirvana> <200704192135.22086.opensource@till.name> Message-ID: <20070419204849.GF13273@neu.nirvana> On Thu, Apr 19, 2007 at 09:35:20PM +0200, Till Maas wrote: > On Do April 19 2007, Axel Thimm wrote: > > > If it's serious: I suspect everyone can identify that something > > matching 2006XXXX or 2007XXXX implies a date, and if not a capital D > > won't help either. > > I would prefer to use YYYY-MM-DD which is easier to read and an ISO conform > afaik. Would this cause any problems with rpm? You can't have any dashes in either epoch/version/release, so you wouldn't be able to have ISO dates in the rpm filename. But since you're going to not match 1005 the tarball's name with the EVR of the package, you could do with the tarball's naming what you want (within reason). You could even add a capital "D" or a greek eta in front of it. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Apr 20 08:14:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 10:14:02 +0200 Subject: [Fedora-packaging] satic libs package naming Message-ID: <20070420081402.GC3045@free.fr> Hello, In the guidelines it is said that static libs subpackages should be called *-static. This triggers lots of rpmlint warnings so I currently use (and propose in reviews) *-static-devel. Should I revert to *-static? If *-static-devel is acceptable, maybe it could be said so in the guidelines. Also, unless I am wrong on that point, maybe in the guidelines there could be a note that when there is only static libraries there is no need of static subpackage and the static libs may be in -devel. -- Pat From rc040203 at freenet.de Fri Apr 20 09:01:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 Apr 2007 11:01:35 +0200 Subject: [Fedora-packaging] satic libs package naming In-Reply-To: <20070420081402.GC3045@free.fr> References: <20070420081402.GC3045@free.fr> Message-ID: <1177059696.30803.153.camel@mccallum.corsepiu.local> On Fri, 2007-04-20 at 10:14 +0200, Patrice Dumas wrote: > Hello, > > In the guidelines it is said that static libs subpackages should be > called *-static. This triggers lots of rpmlint warnings so I currently > use (and propose in reviews) *-static-devel. Should I revert to *-static? > If *-static-devel is acceptable, maybe it could be said so in the > guidelines. The naming "*-static" in the guidelines had been used as synonym and short-cut for what you seem to prefer to call "*-static-devel", because it's considered redundant and because there rarely is any need to provide both static and dynamically linked versions of the same applications. Even if such case should really exist (I am not aware of any such case), one could always resort to package these apps into differently named package. > Also, unless I am wrong on that point, maybe in the guidelines there could > be a note that when there is only static libraries there is no need of > static subpackage and the static libs may be in -devel. Definitely no. This contradicts the basic intentions of the '*-static' rules in the guidelines. One essential intention had been to make "packages that need static linkage" distinguishable from "package that accidentally link static" at the rpm-level. I.e. if a package only supplies static libraries, the "correct approach" would be to package them into *-devel but to let the package also Provide: *-static = %{version}-%{release} Packages "simply using these libs" then would have to BuildRequires: *-devel => They would receive those libs the package contains (normally only the dynamic ones) Packages "intentionally linking static" then would have to BuildRequires: *-static => They would receive the ability to link statically. Ralf From pertusus at free.fr Fri Apr 20 09:35:32 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 11:35:32 +0200 Subject: [Fedora-packaging] satic libs package naming In-Reply-To: <1177059696.30803.153.camel@mccallum.corsepiu.local> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> Message-ID: <20070420093532.GF3045@free.fr> On Fri, Apr 20, 2007 at 11:01:35AM +0200, Ralf Corsepius wrote: > On Fri, 2007-04-20 at 10:14 +0200, Patrice Dumas wrote: > > Hello, > > > > In the guidelines it is said that static libs subpackages should be > > called *-static. This triggers lots of rpmlint warnings so I currently > > use (and propose in reviews) *-static-devel. Should I revert to *-static? > > If *-static-devel is acceptable, maybe it could be said so in the > > guidelines. > The naming "*-static" in the guidelines had been used as synonym and > short-cut for what you seem to prefer to call "*-static-devel", because > it's considered redundant and because there rarely is any need to > provide both static and dynamically linked versions of the same > applications. Even if such case should really exist (I am not aware of > any such case), one could always resort to package these apps into > differently named package. I am not speaking about applications but libs. For example imagine there is the library foo, and for a valid reason I want to package foo as a static lib, not only as a shared lib. My question is can I put libfoo.a in a subpackage called foo-static-devel or has it to be called foo-static (in this scenario, there is alread a foo-devel package with .pc, .so symlinks and headers, and a foo package or a foo-libs with shared libs and maybe data and executables and so on). > > Also, unless I am wrong on that point, maybe in the guidelines there could > > be a note that when there is only static libraries there is no need of > > static subpackage and the static libs may be in -devel. > Definitely no. This contradicts the basic intentions of the '*-static' > rules in the guidelines. > > One essential intention had been to make "packages that need static > linkage" distinguishable from "package that accidentally link static" at > the rpm-level. > > I.e. if a package only supplies static libraries, the "correct approach" > would be to package them into *-devel but to let the package also > Provide: *-static = %{version}-%{release} Ok. Maybe this could be in the guideline? At least I have a package that doesn't follow that rule, maybe there are more. And same question than above, instead of Provide: *-static = %{version}-%{release} could it be Provide: *-static-devel = %{version}-%{release} > Packages "simply using these libs" then would have to > BuildRequires: *-devel > => They would receive those libs the package contains (normally only the > dynamic ones) Ok. > Packages "intentionally linking static" then would have to > BuildRequires: *-static > => They would receive the ability to link statically. I don't think that there should be any package in the fedora collection needing this. (But there are cases when user should be able to link against static libs, a prominent case -- my case -- being numerical models). -- Pat From rc040203 at freenet.de Fri Apr 20 11:06:51 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 Apr 2007 13:06:51 +0200 Subject: [Fedora-packaging] satic libs package naming In-Reply-To: <20070420093532.GF3045@free.fr> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> <20070420093532.GF3045@free.fr> Message-ID: <1177067211.30803.164.camel@mccallum.corsepiu.local> On Fri, 2007-04-20 at 11:35 +0200, Patrice Dumas wrote: > On Fri, Apr 20, 2007 at 11:01:35AM +0200, Ralf Corsepius wrote: > > On Fri, 2007-04-20 at 10:14 +0200, Patrice Dumas wrote: > > > Hello, > > > > > > In the guidelines it is said that static libs subpackages should be > > > called *-static. This triggers lots of rpmlint warnings so I currently > > > use (and propose in reviews) *-static-devel. Should I revert to *-static? > > > If *-static-devel is acceptable, maybe it could be said so in the > > > guidelines. > > The naming "*-static" in the guidelines had been used as synonym and > > short-cut for what you seem to prefer to call "*-static-devel", because > > it's considered redundant and because there rarely is any need to > > provide both static and dynamically linked versions of the same > > applications. Even if such case should really exist (I am not aware of > > any such case), one could always resort to package these apps into > > differently named package. > > I am not speaking about applications but libs. For example imagine there > is the library foo, and for a valid reason I want to package foo as a > static lib, not only as a shared lib. My question is can I put libfoo.a > in a subpackage called > foo-static-devel > or has it to be called > foo-static The guidelines intention is to recommend "foo-static". > (in this scenario, there is alread a foo-devel package with .pc, .so > symlinks and headers, and a foo package or a foo-libs with shared libs and > maybe data and executables and so on). Also consider you are strong encouraged not to ship the static libs and to require FESCO approval. If I was to decide, I would reject any static library unless a pressing need of requiring a static lib can be demonstrated (!). > > > Also, unless I am wrong on that point, maybe in the guidelines there could > > > be a note that when there is only static libraries there is no need of > > > static subpackage and the static libs may be in -devel. > > Definitely no. This contradicts the basic intentions of the '*-static' > > rules in the guidelines. > > > > One essential intention had been to make "packages that need static > > linkage" distinguishable from "package that accidentally link static" at > > the rpm-level. > > > > I.e. if a package only supplies static libraries, the "correct approach" > > would be to package them into *-devel but to let the package also > > Provide: *-static = %{version}-%{release} > > Ok. Maybe this could be in the guideline? At least I have a package that > doesn't follow that rule, maybe there are more. > > And same question than above, instead of > Provide: *-static = %{version}-%{release} > could it be > Provide: *-static-devel = %{version}-%{release} What for? *-static is supposed to be what you seem to prefer to call "*-static-devel". The difference is just the name. > > Packages "simply using these libs" then would have to > > BuildRequires: *-devel > > => They would receive those libs the package contains (normally only the > > dynamic ones) > > Ok. > > > Packages "intentionally linking static" then would have to > > BuildRequires: *-static > > => They would receive the ability to link statically. > > I don't think that there should be any package in the fedora collection > needing this. Exactly ... I can't imagine any. > (But there are cases when user should be able to link > against static libs, a prominent case -- my case -- being numerical > models). You know my opinion on this argument of yours: You are abusing Linux. Ralf From pertusus at free.fr Fri Apr 20 11:13:41 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 13:13:41 +0200 Subject: [Fedora-packaging] satic libs package naming In-Reply-To: <1177067211.30803.164.camel@mccallum.corsepiu.local> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> <20070420093532.GF3045@free.fr> <1177067211.30803.164.camel@mccallum.corsepiu.local> Message-ID: <20070420111341.GG3045@free.fr> On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote: > > The guidelines intention is to recommend "foo-static". Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint? > If I was to decide, I would reject any static library unless a pressing > need of requiring a static lib can be demonstrated (!). There was a very long thread about that issue and I'd like not to repeat it all over again. In summary, there are cases, like numerical models where all the reason that are for dynamic libraries don't make sense (use new version, security, dlopening, name resolution...) while compiling statically helps being able to move programs to other hosts/linux distros/ and so on. The other solution advocated instead of static linking (distributing shared libs along with the program and doing a wrapper that setes things up) is much less practical. Another reason may be the efficiency, as as demonstrated by Enrico numbers on tiny daemons, linking statically may lead to much more efficient executables. > *-static is supposed to be what you seem to prefer to call "*-static-devel". > > The difference is just the name. I don't care about one or the other name, but rpmlint does. > > (But there are cases when user should be able to link > > against static libs, a prominent case -- my case -- being numerical > > models). > You know my opinion on this argument of yours: You are abusing Linux. Not at all. I have specific needs. -- Pat From rc040203 at freenet.de Fri Apr 20 11:27:18 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 Apr 2007 13:27:18 +0200 Subject: [Fedora-packaging] satic libs package naming In-Reply-To: <20070420111341.GG3045@free.fr> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> <20070420093532.GF3045@free.fr> <1177067211.30803.164.camel@mccallum.corsepiu.local> <20070420111341.GG3045@free.fr> Message-ID: <1177068438.30803.172.camel@mccallum.corsepiu.local> On Fri, 2007-04-20 at 13:13 +0200, Patrice Dumas wrote: > On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote: > > > > The guidelines intention is to recommend "foo-static". > > Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint? bugzilla it against rpmlint, if you like to. I don't know where this rpmlint warning stems from. > > If I was to decide, I would reject any static library unless a pressing > > need of requiring a static lib can be demonstrated (!). > > There was a very long thread about that issue and I'd like not to repeat > it all over again. In summary, there are cases, like numerical models > where all the reason that are for dynamic libraries don't make sense (use > new version, security, dlopening, name resolution...) while compiling > statically helps being able to move programs to other hosts/linux > distros/ and so on. The other solution advocated instead of static > linking (distributing shared libs along with the program and doing a > wrapper that setes things up) is much less practical. > > Another reason may be the efficiency, as as demonstrated by Enrico > numbers on tiny daemons, linking statically may lead to much more > efficient executables. What some people call efficiency, I call rending a distro unmaintainable and pimping "Linux" - To me, it's not much different from pimping a car by installing an oxygen bottle to "make it faster". > > > > (But there are cases when user should be able to link > > > against static libs, a prominent case -- my case -- being numerical > > > models). > > You know my opinion on this argument of yours: You are abusing Linux. > > Not at all. I have specific needs. Well, your needs, i.e. "cross-distro binaries", are far from being exotic. Many people before you went into trap you still seem to be trapped into, before you, so be it :-) Ralf From Axel.Thimm at ATrpms.net Fri Apr 20 11:33:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 20 Apr 2007 13:33:48 +0200 Subject: [Fedora-packaging] Re: satic libs package naming In-Reply-To: <20070420111341.GG3045@free.fr> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> <20070420093532.GF3045@free.fr> <1177067211.30803.164.camel@mccallum.corsepiu.local> <20070420111341.GG3045@free.fr> Message-ID: <20070420113348.GE28696@neu.nirvana> On Fri, Apr 20, 2007 at 01:13:41PM +0200, Patrice Dumas wrote: > On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote: > > > > The guidelines intention is to recommend "foo-static". > > Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint? IIRC Ville wanted to speak with upstream to allow *.a in *-static. Maybe he'll comment on what rpmlint currently does and whether upstream perhaps rejected this, or perhaps whether my memory is segfaulting. :) > > *-static is supposed to be what you seem to prefer to call "*-static-devel". > > > > The difference is just the name. > > I don't care about one or the other name, but rpmlint does. What does rpmlint say? I think the idea was to have all, but static libs in *-devel and *.a in *-static. > > > (But there are cases when user should be able to link > > > against static libs, a prominent case -- my case -- being numerical > > > models). > > You know my opinion on this argument of yours: You are abusing Linux. > > Not at all. I have specific needs. I think Ralf means that you are abusing Linux by computing numerical models and doing serious number crunching. Go play a game ;) (P.S. there is a smiley, but nevertheless: the above is a joke!) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Apr 20 11:35:48 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 13:35:48 +0200 Subject: [Fedora-packaging] satic libs package naming In-Reply-To: <1177068438.30803.172.camel@mccallum.corsepiu.local> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> <20070420093532.GF3045@free.fr> <1177067211.30803.164.camel@mccallum.corsepiu.local> <20070420111341.GG3045@free.fr> <1177068438.30803.172.camel@mccallum.corsepiu.local> Message-ID: <20070420113548.GH3045@free.fr> On Fri, Apr 20, 2007 at 01:27:18PM +0200, Ralf Corsepius wrote: > bugzilla it against rpmlint, if you like to. Ok, that's what I'll do. > > Another reason may be the efficiency, as as demonstrated by Enrico > > numbers on tiny daemons, linking statically may lead to much more > > efficient executables. > What some people call efficiency, I call rending a distro unmaintainable > and pimping "Linux" - To me, it's not much different from pimping a car > by installing an oxygen bottle to "make it faster". It may not be at the distro level. But I think that we shouldn't prevent users to link statically their apps when it makes them faster. > Well, your needs, i.e. "cross-distro binaries", are far from being > exotic. Many people before you went into trap you still seem to be > trapped into, before you, so be it :-) I really don't understand what trap you are speaking about. I statically commpile a model on a computer then copy it over to other computers (which may have different shared libraries or even not the libraries at all) and run it (with different parameters of course) using a simple script to drive all the runs. What problem is there with that? -- Pat From rc040203 at freenet.de Fri Apr 20 11:42:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 20 Apr 2007 13:42:59 +0200 Subject: [Fedora-packaging] Re: satic libs package naming In-Reply-To: <20070420113348.GE28696@neu.nirvana> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> <20070420093532.GF3045@free.fr> <1177067211.30803.164.camel@mccallum.corsepiu.local> <20070420111341.GG3045@free.fr> <20070420113348.GE28696@neu.nirvana> Message-ID: <1177069379.30803.181.camel@mccallum.corsepiu.local> On Fri, 2007-04-20 at 13:33 +0200, Axel Thimm wrote: > On Fri, Apr 20, 2007 at 01:13:41PM +0200, Patrice Dumas wrote: > > > > (But there are cases when user should be able to link > > > > against static libs, a prominent case -- my case -- being numerical > > > > models). > > > You know my opinion on this argument of yours: You are abusing Linux. > > > > Not at all. I have specific needs. > > I think Ralf means that you are abusing Linux by computing numerical > models and doing serious number crunching. Go play a game ;) > > (P.S. there is a smiley, but nevertheless: the above is a joke!) Of cause not .. I guess, I know what Pat's "special needs" are: Cross-distro packaging: - Sharing binaries across different distros, e.g. running Fedora built apps on SuSE, Debian, Ubuntu and older RH based distros. - Storing binaries for long-term to be able to reproduce results long time after the distro they had been built on has been EOL'ed - Reproducibility of results by eliminating the impact of multilibs, tls etc. He tries to achieve this by statically linking apps. This works for some very simple apps (Pure numeric apps often qualify as such - Complex mathematical algorithms but very simple wrt. system resources), but doesn't work in general. The g77/gfortran issue he reported in recent days probably are related to this ;) Ralf From pertusus at free.fr Fri Apr 20 12:08:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 14:08:04 +0200 Subject: [Fedora-packaging] Re: satic libs package naming In-Reply-To: <1177069379.30803.181.camel@mccallum.corsepiu.local> References: <20070420081402.GC3045@free.fr> <1177059696.30803.153.camel@mccallum.corsepiu.local> <20070420093532.GF3045@free.fr> <1177067211.30803.164.camel@mccallum.corsepiu.local> <20070420111341.GG3045@free.fr> <20070420113348.GE28696@neu.nirvana> <1177069379.30803.181.camel@mccallum.corsepiu.local> Message-ID: <20070420120804.GI3045@free.fr> On Fri, Apr 20, 2007 at 01:42:59PM +0200, Ralf Corsepius wrote: > > Of cause not .. I guess, I know what Pat's "special needs" are: > Cross-distro packaging: > > - Sharing binaries across different distros, e.g. running Fedora built > apps on SuSE, Debian, Ubuntu and older RH based distros. Exactly. Statically linked libc requires a recent enough kernel, this is what is currently limiting the portability of the executables I generate. > - Storing binaries for long-term to be able to reproduce results long > time after the distro they had been built on has been EOL'ed In fact this doesn't work very well if I remember what was said in the long thread I referred to. > - Reproducibility of results by eliminating the impact of multilibs, tls > etc. That is not one of my needs, but some scientists need that. I am not convinced that statically linking is a definite solution, but it may help. > He tries to achieve this by statically linking apps. This works for some > very simple apps (Pure numeric apps often qualify as such - Complex > mathematical algorithms but very simple wrt. system resources), but > doesn't work in general. I agree with you that it doesn't work in general, but it works well for me and I believe my case is very common within scientists: * use only mathematical libs * have heterogeneous linuxes (both in time and in distros) * want to run on all the computers in the lab > The g77/gfortran issue he reported in recent days probably are related > to this ;) Not exactly, but indeed statically compiling allows to compile with a compiler and run on a platform where it isn't supported. g77 ICE on some of my codes, so I cannot recompile on some distros, but still can run gfortan compiled codes on those distros. Static linking is not always needed, but in practice it is, for example when libgfortran isn't available. -- Pat From ville.skytta at iki.fi Fri Apr 20 14:42:44 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 20 Apr 2007 17:42:44 +0300 Subject: [Fedora-packaging] Re: satic libs package naming In-Reply-To: <20070420113348.GE28696@neu.nirvana> References: <20070420081402.GC3045@free.fr> <20070420111341.GG3045@free.fr> <20070420113348.GE28696@neu.nirvana> Message-ID: <200704201742.44730.ville.skytta@iki.fi> On Friday 20 April 2007, Axel Thimm wrote: > On Fri, Apr 20, 2007 at 01:13:41PM +0200, Patrice Dumas wrote: > > On Fri, Apr 20, 2007 at 01:06:51PM +0200, Ralf Corsepius wrote: > > > The guidelines intention is to recommend "foo-static". > > > > Ok, so what about rpmlint warnings? Ignore them or bugzilla rpmlint? > > IIRC Ville wanted to speak with upstream to allow *.a in > *-static. Maybe he'll comment on what rpmlint currently does and > whether upstream perhaps rejected this, or perhaps whether my memory > is segfaulting. :) rpmlint 0.80 treats *-static as devel packages, earlier versions don't. From Axel.Thimm at ATrpms.net Mon Apr 23 10:11:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Apr 2007 12:11:35 +0200 Subject: [Fedora-packaging] Using %global instead of %define in conditionalized macro expressions Message-ID: <20070423101135.GF1248@neu.nirvana> Or to place it more explicit make %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} [%{!?foo: %define foo ...}] to %{!?python_sitelib:%global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} [%{!?foo:%global foo ...}] Otherwise using parametrized macros can mess things up (#237448). The nesting levels seems to get mixed up and the conditionalized definition above get swallowed away. The %global ensures that this bug doesn't happen. It may also be cleaner to remove the space between the colon and the percent sign. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Apr 24 15:33:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Apr 2007 17:33:27 +0200 Subject: [Fedora-packaging] Re: Using %global instead of %define in conditionalized macro expressions In-Reply-To: <20070423101135.GF1248@neu.nirvana> References: <20070423101135.GF1248@neu.nirvana> Message-ID: <20070424153327.GV633@neu.nirvana> On Mon, Apr 23, 2007 at 12:11:35PM +0200, Axel Thimm wrote: > Or to place it more explicit make > > %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} > %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > [%{!?foo: %define foo ...}] > > to > > %{!?python_sitelib:%global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} > %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > [%{!?foo:%global foo ...}] > > Otherwise using parametrized macros can mess things up (#237448). The > nesting levels seems to get mixed up and the conditionalized > definition above get swallowed away. The %global ensures that this > bug doesn't happen. OK, looks like the bug is indeed in using this construct with %define inside. rpm's lazy garbage collection pollutes the global macor namespace until a more involved nesting construct appears which properly cleans up. So we really need to change %defines within a %{...} to %globals. Let's vote on this today unless s/o thinks he needs to investigate further. > It may also be cleaner to remove the space between the colon and the > percent sign. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Apr 24 19:30:42 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Apr 2007 14:30:42 -0500 Subject: [Fedora-packaging] http://fedoraproject.org/wiki/Packaging/NewMeetingTime Message-ID: <1177443042.5956.38.camel@localhost.localdomain> FPC members: Please go to http://fedoraproject.org/wiki/Packaging/NewMeetingTime and put in times which will work for you to attend. I've also put in the other times which are already taken in #fedora-meeting, so that we don't accidentally choose a time which is already in use. Thanks in advance, ~spot From Axel.Thimm at ATrpms.net Tue Apr 24 19:46:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Apr 2007 21:46:50 +0200 Subject: [Fedora-packaging] Re: Using %global instead of %define In-Reply-To: <20070424153327.GV633@neu.nirvana> References: <20070423101135.GF1248@neu.nirvana> <20070424153327.GV633@neu.nirvana> Message-ID: <20070424194650.GI3031@neu.nirvana> We unanimously agreed to this, and we decided to take this even further to generally discourage use of %define in favour of %global. I created a proposal for the guidelines at http://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define It also contains the Packaging/* pages that need editing, which I eye-ball-checked that they only contain trivial %defines. On Tue, Apr 24, 2007 at 05:33:27PM +0200, Axel Thimm wrote: > On Mon, Apr 23, 2007 at 12:11:35PM +0200, Axel Thimm wrote: > > Or to place it more explicit make > > > > %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} > > %{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > [%{!?foo: %define foo ...}] > > > > to > > > > %{!?python_sitelib:%global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} > > %{!?python_sitearch:%global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} > > [%{!?foo:%global foo ...}] > > > > Otherwise using parametrized macros can mess things up (#237448). The > > nesting levels seems to get mixed up and the conditionalized > > definition above get swallowed away. The %global ensures that this > > bug doesn't happen. > > OK, looks like the bug is indeed in using this construct with %define > inside. rpm's lazy garbage collection pollutes the global macor > namespace until a more involved nesting construct appears which > properly cleans up. > > So we really need to change %defines within a %{...} to %globals. > > Let's vote on this today unless s/o thinks he needs to investigate > further. > > > It may also be cleaner to remove the space between the colon and the > > percent sign. > > > > > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Tue Apr 24 19:51:51 2007 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 24 Apr 2007 15:51:51 -0400 Subject: [Fedora-packaging] Re: Using %global instead of %define In-Reply-To: <20070424194650.GI3031@neu.nirvana> References: <20070423101135.GF1248@neu.nirvana> <20070424153327.GV633@neu.nirvana> <20070424194650.GI3031@neu.nirvana> Message-ID: <1177444311.16255.101.camel@cassandra.boston.redhat.com> On Tue, 2007-04-24 at 21:46 +0200, Axel Thimm wrote: > We unanimously agreed to this, and we decided to take this even > further to generally discourage use of %define in favour of %global. I > created a proposal for the guidelines at > > http://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define > > It also contains the Packaging/* pages that need editing, which I > eye-ball-checked that they only contain trivial %defines. > Can rpmlint detect a %define that should be a %global ? (or could it be extended to perform such a test?) It would be nice to be able to automatically detect such possibly problematic cases. From jcm at redhat.com Tue Apr 24 19:52:03 2007 From: jcm at redhat.com (Jon Masters) Date: Tue, 24 Apr 2007 15:52:03 -0400 Subject: [Fedora-packaging] Re: Using %global instead of %define In-Reply-To: <20070424194650.GI3031@neu.nirvana> References: <20070423101135.GF1248@neu.nirvana> <20070424153327.GV633@neu.nirvana> <20070424194650.GI3031@neu.nirvana> Message-ID: <1177444323.4778.8.camel@jcmlaptop> On Tue, 2007-04-24 at 21:46 +0200, Axel Thimm wrote: > We unanimously agreed to this, and we decided to take this even > further to generally discourage use of %define in favour of %global. I > created a proposal for the guidelines at > > http://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define I agree with this in the case of large macro expansions or cases where nesting might occur. Incidentally, there's a very limited stack size on macro expansions (8192 bytes currently) that is an annoyance when you've got deeply nested macros. I'd love to see that limitation go away :-) Jon. From tibbs at math.uh.edu Tue Apr 24 20:19:08 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Apr 2007 15:19:08 -0500 Subject: [Fedora-packaging] http://fedoraproject.org/wiki/Packaging/NewMeetingTime In-Reply-To: <1177443042.5956.38.camel@localhost.localdomain> References: <1177443042.5956.38.camel@localhost.localdomain> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> I've also put in the other times which are already taken in TC> #fedora-meeting, so that we don't accidentally choose a time which TC> is already in use. I think the FESCO time is incorrect; it's currently at 17:00UTC. Note that I'm blocked out from 20:00 to 21:00 but I can actually be available until 20:30 if it comes down to that. - J< From tcallawa at redhat.com Tue Apr 24 20:28:52 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 24 Apr 2007 15:28:52 -0500 Subject: [Fedora-packaging] http://fedoraproject.org/wiki/Packaging/NewMeetingTime In-Reply-To: References: <1177443042.5956.38.camel@localhost.localdomain> Message-ID: <1177446532.5956.42.camel@localhost.localdomain> On Tue, 2007-04-24 at 15:19 -0500, Jason L Tibbitts III wrote: > >>>>> "TC" == Tom \"spot\" Callaway writes: > > TC> I've also put in the other times which are already taken in > TC> #fedora-meeting, so that we don't accidentally choose a time which > TC> is already in use. > > I think the FESCO time is incorrect; it's currently at 17:00UTC. > > Note that I'm blocked out from 20:00 to 21:00 but I can actually be > available until 20:30 if it comes down to that. I pulled the meeting times directly from: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel So, it may be wrong there. :) ~spot From ville.skytta at iki.fi Wed Apr 25 19:19:36 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 25 Apr 2007 22:19:36 +0300 Subject: [Fedora-packaging] First user/group handling discussion draft Message-ID: <200704252219.37024.ville.skytta@iki.fi> Hello, The first draft about user and group handling (creation etc) is ready for discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups The draft was presented in yesterday's FPC meeting, but the quick conclusion was that it'd be better to discuss it on list first. The draft currently contains only an implementation of the all-dynamic uid/gid mapping scheme - more may follow later if the consensus is that other schemes are actually required in packages (ie. not adequately addressable outside of them). From rc040203 at freenet.de Mon Apr 30 13:03:10 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 30 Apr 2007 15:03:10 +0200 Subject: [Fedora-packaging] missing tomorrow's FPC meeting Message-ID: <1177938190.4283.43.camel@mccallum.corsepiu.local> Hi, Due to a public holiday in Germany, I'll be AFK most of the day and therefore probably will not be able to attend the FPC meeting. No matter if it will take place at 17:00 or 16:00 UTC ;) Ralf From Axel.Thimm at ATrpms.net Mon Apr 30 20:04:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Apr 2007 22:04:43 +0200 Subject: [Fedora-packaging] Re: missing tomorrow's FPC meeting In-Reply-To: <1177938190.4283.43.camel@mccallum.corsepiu.local> References: <1177938190.4283.43.camel@mccallum.corsepiu.local> Message-ID: <20070430200443.GG13906@neu.nirvana> Hi, On Mon, Apr 30, 2007 at 03:03:10PM +0200, Ralf Corsepius wrote: > Hi, > > Due to a public holiday in Germany, I'll be AFK most of the day and > therefore probably will not be able to attend the FPC meeting. > > No matter if it will take place at 17:00 or 16:00 UTC ;) > > Ralf the same is true for me. Ralf, and anyone else holidaying around: have fun! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: