From trond.danielsen at gmail.com Sun Apr 1 08:56:29 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Sun, 1 Apr 2007 10:56:29 +0200 Subject: Bug in SDCC that depends on Lyx Message-ID: <409676c70704010156s8ae7ae6xbd6803f809d30044@mail.gmail.com> Hi, the documentation for sdcc does not build because of a problem with the latest version of lyx. I have already filed a bug for lyx, but I wonder if it is normal to file a bug for sdcc too? For the record, I am the maintainer of sdcc. -- Trond Danielsen From trond.danielsen at gmail.com Sun Apr 1 08:57:11 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Sun, 1 Apr 2007 10:57:11 +0200 Subject: Bug in SDCC that depends on Lyx In-Reply-To: <409676c70704010156s8ae7ae6xbd6803f809d30044@mail.gmail.com> References: <409676c70704010156s8ae7ae6xbd6803f809d30044@mail.gmail.com> Message-ID: <409676c70704010157n36e4aabcr9e6f5ef4c81a3702@mail.gmail.com> 2007/4/1, Trond Danielsen : > Hi, > > the documentation for sdcc does not build because of a problem with > the latest version of lyx. I have already filed a bug for lyx, but I > wonder if it is normal to file a bug for sdcc too? For the record, I > am the maintainer of sdcc. I forgot to add a link to the lyx bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234738 -- Trond Danielsen From jamatos at fc.up.pt Sun Apr 1 09:19:22 2007 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Sun, 1 Apr 2007 10:19:22 +0100 Subject: Bug in SDCC that depends on Lyx In-Reply-To: <409676c70704010157n36e4aabcr9e6f5ef4c81a3702@mail.gmail.com> References: <409676c70704010156s8ae7ae6xbd6803f809d30044@mail.gmail.com> <409676c70704010157n36e4aabcr9e6f5ef4c81a3702@mail.gmail.com> Message-ID: <200704011019.22137.jamatos@fc.up.pt> On Sunday 01 April 2007 9:57:11 am Trond Danielsen wrote: > > I forgot to add a link to the lyx bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234738 And here it is the one line patch that fixes it: http://www.lyx.org/trac/changeset/17666 -- Jos? Ab?lio From trond.danielsen at gmail.com Sun Apr 1 09:40:42 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Sun, 1 Apr 2007 11:40:42 +0200 Subject: Bug in SDCC that depends on Lyx In-Reply-To: <200704011019.22137.jamatos@fc.up.pt> References: <409676c70704010156s8ae7ae6xbd6803f809d30044@mail.gmail.com> <409676c70704010157n36e4aabcr9e6f5ef4c81a3702@mail.gmail.com> <200704011019.22137.jamatos@fc.up.pt> Message-ID: <409676c70704010240rbdac6b4l34369d29ebefb635@mail.gmail.com> 2007/4/1, Jos? Matos : > On Sunday 01 April 2007 9:57:11 am Trond Danielsen wrote: > > > > I forgot to add a link to the lyx bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234738 > > And here it is the one line patch that fixes it: > http://www.lyx.org/trac/changeset/17666 Great! I'll add that link to the bug report, so hopefully it will be fixed. -- Trond Danielsen From belegdol at gmail.com Sun Apr 1 10:58:14 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 01 Apr 2007 12:58:14 +0200 Subject: How to load a kernel module automatically? Message-ID: <460F9046.2020405@gmail.gom> Hi. In my effort to update thinkfinger to 0.3, I have noticed that the new version requires uinput module to be loaded. My question is, how to solve thins in rpm? I.e what scriptlets/config files to add so that uinput would be added to the list of automatically loaded ones upon install and removed upon erase. Cheers, JS From opensource at till.name Sun Apr 1 11:36:58 2007 From: opensource at till.name (Till Maas) Date: Sun, 01 Apr 2007 13:36:58 +0200 Subject: How to load a kernel module automatically? In-Reply-To: <460F9046.2020405@gmail.gom> References: <460F9046.2020405@gmail.gom> Message-ID: <200704011337.06619.opensource@till.name> On So April 1 2007, Julian Sikorski wrote: > Hi. In my effort to update thinkfinger to 0.3, I have noticed that the > new version requires uinput module to be loaded. My question is, how to > solve thins in rpm? I.e what scriptlets/config files to add so that > uinput would be added to the list of automatically loaded ones upon > install and removed upon erase. I would do the following: In /etc/sysconfig/modules/thinkfinger.modules (needs to be executable): #!/bin/sh /sbin/modprobe uinput &>/dev/null In the spec: %post %{_sysconfdir}/sysconf/modules/%{name}.modules || : %preun rmmod uinput || : /etc/sysconfig/modules/*.modules are executed at boottime, and the scriptlets load and remove the module at the right moment. 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 ville.skytta at iki.fi Sun Apr 1 15:36:42 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 1 Apr 2007 18:36:42 +0300 Subject: How to load a kernel module automatically? In-Reply-To: <200704011337.06619.opensource@till.name> References: <460F9046.2020405@gmail.gom> <200704011337.06619.opensource@till.name> Message-ID: <200704011836.43268.ville.skytta@iki.fi> On Sunday 01 April 2007, Till Maas wrote: > > In the spec: > > %post > %{_sysconfdir}/sysconf/modules/%{name}.modules || : > > %preun > rmmod uinput || : > > /etc/sysconfig/modules/*.modules are executed at boottime, and the > scriptlets load and remove the module at the right moment. %post above is broken, it'll fail to do the right thing if the module is already loaded. %preun is broken too, it'll cause the module to be removed on package upgrades (assuming it succeeds). The scriptlets above also don't take into account if the package being installed/upgraded/erased contains modules for the currently running kernel in the first place; if not, they're not desirable. I think it's generally better to not try adding/removing modules in scriptlets at all, but just do the depmod -a(e) for the correct kernel. From kwade at redhat.com Sun Apr 1 17:06:21 2007 From: kwade at redhat.com (Karsten Wade) Date: Sun, 01 Apr 2007 10:06:21 -0700 Subject: last chance relnotes for test4 Message-ID: <1175447181.3278.57.camel@erato.phig.org> Tomorrow (2 April) at 2359 UTC we are freezing the Wiki for conversion to XML. http://fedoraproject.org/wiki/Docs/Beats The content in the Wiki then gets translated and included in test4. If you get content in *now* you can get it read and tested by the community. The same holds true for the translations. It's stupidly easy to get notes in, there is nothing stopping you: http://fedoraproject.org/wiki/Docs/Beats/HowTo There are six ways to get notes in, as easy as sending an email, and we'll even do the Wiki work for you. Don't hesitate, send it! - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 belegdol at gmail.com Sun Apr 1 17:43:02 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 01 Apr 2007 19:43:02 +0200 Subject: How to load a kernel module automatically? In-Reply-To: <200704011836.43268.ville.skytta@iki.fi> References: <460F9046.2020405@gmail.gom> <200704011337.06619.opensource@till.name> <200704011836.43268.ville.skytta@iki.fi> Message-ID: <460FEF26.1000607@gmail.gom> Ville Skytt? napisa?(a): > I think it's generally better to not try adding/removing > modules in scriptlets at all, but just do the depmod -a(e) for the correct > kernel. Could you be a bit more specific? From opensource at till.name Sun Apr 1 17:51:52 2007 From: opensource at till.name (Till Maas) Date: Sun, 01 Apr 2007 19:51:52 +0200 Subject: How to load a kernel module automatically? In-Reply-To: <200704011836.43268.ville.skytta@iki.fi> References: <460F9046.2020405@gmail.gom> <200704011337.06619.opensource@till.name> <200704011836.43268.ville.skytta@iki.fi> Message-ID: <200704011952.15347.opensource@till.name> On So April 1 2007, Ville Skytt? wrote: > %post above is broken, it'll fail to do the right thing if the module is > already loaded. %preun is broken too, it'll cause the module to be removed > on package upgrades (assuming it succeeds). I do not understand, why this is broken. When updating a kernel module, unloading it in %preun and loading the new one in %post seems to me to be the desired behaviour. At least this is what I expect as a user. And when the module is currently used, so it cannot be removed, then there is imho nothing useful the system could do, instead of nothing, which is what will happen with the scriptlets. > The scriptlets above also > don't take into account if the package being installed/upgraded/erased > contains modules for the currently running kernel in the first place; if > not, they're not desirable. As far as I understand the scriptlets, they will silently fail when one installs the wrong kernel-module, but why should this happen in reality? > I think it's generally better to not try > adding/removing modules in scriptlets at all, but just do the depmod -a(e) > for the correct kernel. For me it would be annoying to manually have to reload a module, when this could happen automatically. Also you did not explain what is going wrong with these scriptlets except that they would do nothing in some cases. 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 ville.skytta at iki.fi Sun Apr 1 18:10:32 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 1 Apr 2007 21:10:32 +0300 Subject: How to load a kernel module automatically? In-Reply-To: <460FEF26.1000607@gmail.gom> References: <460F9046.2020405@gmail.gom> <200704011836.43268.ville.skytta@iki.fi> <460FEF26.1000607@gmail.gom> Message-ID: <200704012110.32881.ville.skytta@iki.fi> On Sunday 01 April 2007, Julian Sikorski wrote: > Ville Skytt? napisa?(a): > > I think it's generally better to not try adding/removing > > modules in scriptlets at all, but just do the depmod -a(e) for the > > correct kernel. > > Could you be a bit more specific? When taking everything that needs to be taken into account, the scriptlets get more than a little hairy. My previous mail scratches the surface of packaging related problems with it. Further things to consider: Can you be sure that removing a module won't screw the runtime system's state some way (for example, for practical purposes, some hardware which may be essential to the user (which you as the packager can't know) can disappear on the fly, just like that)? And what do you do if the module removal fails on package upgrades? What if it fails on package erase time? From ville.skytta at iki.fi Sun Apr 1 18:27:17 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 1 Apr 2007 21:27:17 +0300 Subject: How to load a kernel module automatically? In-Reply-To: <200704011952.15347.opensource@till.name> References: <460F9046.2020405@gmail.gom> <200704011836.43268.ville.skytta@iki.fi> <200704011952.15347.opensource@till.name> Message-ID: <200704012127.17543.ville.skytta@iki.fi> On Sunday 01 April 2007, Till Maas wrote: > When updating a kernel module, > unloading it in %preun and loading the new one in %post seems to me to be > the desired behaviour. As with all packages on upgrades, %post of the new package is run before %preun of the old. > > The scriptlets above also > > don't take into account if the package being installed/upgraded/erased > > contains modules for the currently running kernel in the first place; if > > not, they're not desirable. > > As far as I understand the scriptlets, they will silently fail when one > installs the wrong kernel-module, but why should this happen in reality? What's "wrong kernel module"? And it happens every time one updates a kernel and installs module packages for it while still running some other kernel + modules. Or erasing an old kernel and some module packages for it while running a newer kernel + modules. > Also you did not explain what is going wrong > with these scriptlets except that they would do nothing in some cases. You got it backwards, the simplistic scriptlets posted would do things in situations where they shouldn't be doing anything (this depends on the packaging scheme used - I'm assuming you're using the http://fedoraproject.org/wiki/Packaging/KernelModules one). Example: running kernel version X and foo modules for it. Install kernel version Y and corresponding foo modules for it -> the installation would try to insmod the foo module _for kernel X_. Remove kernel version Y and foo modules for it while still running kernel X -> the erase would try to remove the modules _from the running kernel X_. From Axel.Thimm at ATrpms.net Sun Apr 1 18:38:20 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 1 Apr 2007 20:38:20 +0200 Subject: How to load a kernel module automatically? In-Reply-To: <200704011952.15347.opensource@till.name> References: <460F9046.2020405@gmail.gom> <200704011337.06619.opensource@till.name> <200704011836.43268.ville.skytta@iki.fi> <200704011952.15347.opensource@till.name> Message-ID: <20070401183820.GF15714@neu.nirvana> On Sun, Apr 01, 2007 at 07:51:52PM +0200, Till Maas wrote: > I do not understand, why this is broken. When updating a kernel module, > unloading it in %preun and loading the new one in %post seems to me to be the > desired behaviour. But that's not the order rpm will call your scriptlets. First the new ones are called, then the old ones. -- 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 sundaram at fedoraproject.org Mon Apr 2 08:01:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Apr 2007 13:31:20 +0530 Subject: New packages this week Message-ID: <4610B850.10005@fedoraproject.org> Hi fedoranews.org is merging with fedoraproject.org soon and I have volunteered to a do a new section that lists and perhaps explains what new packages have been introduced this week. Is there a equivalent of http://packages.debian.org/unstable/newpkg_main? If not, what would be the quickest way to list the new packages in extras, short descriptions as well as the branches? Rahul From ml at deadbabylon.de Mon Apr 2 09:00:21 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 2 Apr 2007 11:00:21 +0200 Subject: New packages this week In-Reply-To: <4610B850.10005@fedoraproject.org> References: <4610B850.10005@fedoraproject.org> Message-ID: <20070402110021.62203177@localhost.localdomain> Am Mon, 02 Apr 2007 13:31:20 +0530 schrieb Rahul Sundaram : > Hi > > fedoranews.org is merging with fedoraproject.org soon and I have > volunteered to a do a new section that lists and perhaps explains > what new packages have been introduced this week. Is there a > equivalent of http://packages.debian.org/unstable/newpkg_main? If > not, what would be the quickest way to list the new packages in > extras, short descriptions as well as the branches? There seems not to be an equivalent. A few months ago I've also asked for that [1] and also voluntered to do this. But at that time Thomas Chung seems not to be interested. So I've done this for my own (eg. http://www.fedorausers.de/?q=node/28). This one is done all manually. Sebastian [1] http://article.gmane.org/gmane.linux.redhat.fedora.extras.general/31601 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon Apr 2 09:19:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 02 Apr 2007 11:19:02 +0200 Subject: New packages this week In-Reply-To: <4610B850.10005@fedoraproject.org> References: <4610B850.10005@fedoraproject.org> Message-ID: <4610CA86.6010708@leemhuis.info> On 02.04.2007 10:01, Rahul Sundaram wrote: > If not, what would be > the quickest way to list the new packages in extras, short descriptions > as well as the branches? A script that uses repoquery could do what you want. But it might take a bit of time (one our two hours? no idea..) to write that. CU thl From trond.danielsen at fedoraproject.org Mon Apr 2 09:19:45 2007 From: trond.danielsen at fedoraproject.org (Trond Danielsen) Date: Mon, 2 Apr 2007 11:19:45 +0200 Subject: New packages this week In-Reply-To: <4610B850.10005@fedoraproject.org> References: <4610B850.10005@fedoraproject.org> Message-ID: <409676c70704020219y30284df3s3eccd820f0bd865@mail.gmail.com> 2007/4/2, Rahul Sundaram : > Hi > > fedoranews.org is merging with fedoraproject.org soon and I have > volunteered to a do a new section that lists and perhaps explains what > new packages have been introduced this week. Is there a equivalent of > http://packages.debian.org/unstable/newpkg_main? If not, what would be > the quickest way to list the new packages in extras, short descriptions > as well as the branches? Did you try "yum info recent"? If thats not good enough, you can try this cheezy script: - - - - - - - #!/bin/sh MONTH=$(LC_ALL=C date +"%Y-%B") FILE_NAME=$MONTH.txt URL=https://www.redhat.com/archives/fedora-devel-list/ TMP_DIR=$(mktemp -d) pushd $TMP_DIR > /dev/null rm -f $FILE_NAME* wget -q $URL/$FILE_NAME.gz gunzip $FILE_NAME.gz NEW_PACKAGES=$(grep "^NEW" $MONTH.txt | cut -d' ' -f3) yum info $NEW_PACKAGES popd > /dev/null rm -rf TMP_DIR - - - - - - - Cheers, -- Trond Danielsen From sundaram at fedoraproject.org Mon Apr 2 09:32:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 02 Apr 2007 15:02:25 +0530 Subject: Package conflicts Message-ID: <4610CDA9.9020001@fedoraproject.org> Hi I was trying out smart when yum dep resolving was slow in rawhide a while back. smart stats reports that there is a total 1357 conflicts in fedora-devel+extras-devel. Isn't that way too much? Rahul From bugs.michael at gmx.net Mon Apr 2 10:16:36 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 Apr 2007 12:16:36 +0200 Subject: Package conflicts In-Reply-To: <4610CDA9.9020001@fedoraproject.org> References: <4610CDA9.9020001@fedoraproject.org> Message-ID: <20070402121636.27b436ee.bugs.michael@gmx.net> On Mon, 02 Apr 2007 15:02:25 +0530, Rahul Sundaram wrote: > Hi > > I was trying out smart when yum dep resolving was slow in rawhide a > while back. smart stats reports that there is a total 1357 conflicts in > fedora-devel+extras-devel. > > Isn't that way too much? Yes. Here are the conflicts I find in Extras devel compared with Core devel. They are filed (see FE7Target tracker). Comments inline as there is one false positive. clearsilver - 0.10.4-2.fc7.i386 File conflict with: csound - 5.03.0-9.fc7.i386 /usr/bin/cs csound - 5.03.0-9.fc7.i386 File conflict with: clearsilver - 0.10.4-2.fc7.i386 /usr/bin/cs File conflict with: html-xml-utils - 3.7-4.fc6.i386 /usr/bin/extract File conflict with: libextractor - 0.5.17a-1.fc7.i386 /usr/bin/extract cyrus-imapd - 2.3.8-1.fc7.i386 File conflict with: uw-imap - 2006e-2.fc7.i386 /etc/pam.d/imap /etc/pam.d/pop /usr/share/man/man8/imapd.8.gz fish - 1.21.12-1.fc6.i386 File conflict with: html-xml-utils - 3.7-4.fc6.i386 /usr/bin/count /usr/share/man/man1/count.1.gz grass - 6.2.1-13.fc7.i386 File conflict with: rubygems - 0.9.2-1.fc7.noarch /usr/bin/gem html-xml-utils - 3.7-4.fc6.i386 File conflict with: csound - 5.03.0-9.fc7.i386 /usr/bin/extract File conflict with: fish - 1.21.12-1.fc6.i386 /usr/bin/count /usr/share/man/man1/count.1.gz File conflict with: libextractor - 0.5.17a-1.fc7.i386 /usr/bin/extract libextractor - 0.5.17a-1.fc7.i386 File conflict with: csound - 5.03.0-9.fc7.i386 /usr/bin/extract File conflict with: html-xml-utils - 3.7-4.fc6.i386 /usr/bin/extract php-pear-PHPUnit - 3.0.5-3.fc7.noarch File conflict with: php-pear-PHPUnit2 - 2.3.6-1.fc6.noarch [snip] This is not true, as php-pear-PHPUnit obsoletes php-pear(PHPUnit2) < 3.0.0, which is one of the special cases I don't cover yet. plib-devel - 1.8.4-8.fc6.i386 File conflict with: plib16-devel - 1.6.0-6.fc6.i386 /usr/include/plib/fnt.h /usr/include/plib/js.h /usr/include/plib/netBuffer.h /usr/include/plib/netChannel.h /usr/include/plib/netMessage.h /usr/include/plib/netMonitor.h /usr/include/plib/netSocket.h /usr/include/plib/pu.h /usr/include/plib/sg.h /usr/include/plib/sl.h /usr/include/plib/slPortability.h /usr/include/plib/sm.h /usr/include/plib/ssg.h /usr/include/plib/ssgAux.h /usr/include/plib/ssgKeyFlier.h /usr/include/plib/ssgaWaveSystem.h /usr/include/plib/ssgconf.h /usr/include/plib/ul.h /usr/include/plib/ulRTTI.h plib16-devel - 1.6.0-6.fc6.i386 File conflict with: plib-devel - 1.8.4-8.fc6.i386 /usr/include/plib/fnt.h /usr/include/plib/js.h /usr/include/plib/netBuffer.h /usr/include/plib/netChannel.h /usr/include/plib/netMessage.h /usr/include/plib/netMonitor.h /usr/include/plib/netSocket.h /usr/include/plib/pu.h /usr/include/plib/sg.h /usr/include/plib/sl.h /usr/include/plib/slPortability.h /usr/include/plib/sm.h /usr/include/plib/ssg.h /usr/include/plib/ssgAux.h /usr/include/plib/ssgKeyFlier.h /usr/include/plib/ssgaWaveSystem.h /usr/include/plib/ssgconf.h /usr/include/plib/ul.h /usr/include/plib/ulRTTI.h rubygems - 0.9.2-1.fc7.noarch File conflict with: grass - 6.2.1-13.fc7.i386 /usr/bin/gem uw-imap - 2006e-2.fc7.i386 File conflict with: cyrus-imapd - 2.3.8-1.fc7.i386 /etc/pam.d/imap /etc/pam.d/pop /usr/share/man/man8/imapd.8.gz From lemenkov at gmail.com Mon Apr 2 12:51:30 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 2 Apr 2007 16:51:30 +0400 Subject: Fedora for tiny devices - exessive dependencies Message-ID: Hello All! Is anyone interested in using Fedora Core as a (for example) file-server? It was really upset me then I discovered that a typical installation (NFS, SAMBA, ftp and administrative tools), can't be fitted onto a 128- or 256-mbyte-sized partition (inexpensive flash-disk). Even today, then there are a lot of 70-80$ (typical price in Moscow) 1Gbyte flash-disks there are things that I can't accept. For instance - we have a grub depending on 8mbyte-sized bulk of funny pictures called fedora-logos. I saw another strange and very expensive dependencies but always forget to create a bookmark. Another one thing I want to mention - is there a way to tell yum to use --excludedocs flag? It should save another few tens of megabytes? -- With best regards! From wolfy at nobugconsulting.ro Mon Apr 2 13:05:39 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 02 Apr 2007 16:05:39 +0300 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: <4610FFA3.5090001@nobugconsulting.ro> Peter Lemenkov wrote: > > Another one thing I want to mention - is there a way to tell yum to > use --excludedocs flag? It should save another few tens of megabytes? > echo "define %_excludedocs 1" >> ~/.rpmmacros From ville.skytta at iki.fi Mon Apr 2 13:06:43 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 2 Apr 2007 16:06:43 +0300 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: <200704021606.43915.ville.skytta@iki.fi> On Monday 02 April 2007, Peter Lemenkov wrote: > Another one thing I want to mention - is there a way to tell yum to > use --excludedocs flag? echo "%_excludedocs 1" >> /etc/rpm/macros > It should save another few tens of megabytes? It does. And my guess is that in F7 --excludedocs installs are much more feasible than in earlier distro versions - a lot of packages have had their install-info scriptlets made failsafe. Some work remains though, at least: https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=failsafe+install-info From mmcgrath at redhat.com Mon Apr 2 13:09:16 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 02 Apr 2007 08:09:16 -0500 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: <4611007C.4070909@redhat.com> Peter Lemenkov wrote: > Hello All! > > Is anyone interested in using Fedora Core as a (for example) > file-server? It was really upset me then I discovered that a typical > installation (NFS, SAMBA, ftp and administrative tools), can't be > fitted onto a 128- or 256-mbyte-sized partition (inexpensive > flash-disk). take a closer look at redhat-lsb. rpm -q --requires redhat-lsb Using kickstart you can remove these packages to make the install much smaller. -Mike From lemenkov at gmail.com Mon Apr 2 13:22:06 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 2 Apr 2007 17:22:06 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704021606.43915.ville.skytta@iki.fi> References: <200704021606.43915.ville.skytta@iki.fi> Message-ID: 2007/4/2, Ville Skytt? : > On Monday 02 April 2007, Peter Lemenkov wrote: > > > Another one thing I want to mention - is there a way to tell yum to > > use --excludedocs flag? > > echo "%_excludedocs 1" >> /etc/rpm/macros OK, I did something similar - I added tsflags=nodocs into /etc/yum.conf Now I want to now - how could I remove already installed docs properly? I simply execuyte the following line: # rm -rf /usr/share/docs/* But I suspect that there is a more smart solution. -- With best regards! From lemenkov at gmail.com Mon Apr 2 13:28:33 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 2 Apr 2007 17:28:33 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: <200704021606.43915.ville.skytta@iki.fi> Message-ID: > OK, I did something similar - I added tsflags=nodocs into /etc/yum.conf > Now I want to now - how could I remove already installed docs > properly? I simply execuyte the following line: > > # rm -rf /usr/share/docs/* > > But I suspect that there is a more smart solution. Already found by myself! ) rpm -qad prints full list of docs -- With best regards! From wolfy at nobugconsulting.ro Mon Apr 2 13:55:17 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 02 Apr 2007 16:55:17 +0300 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: <200704021606.43915.ville.skytta@iki.fi> Message-ID: <46110B45.8090702@nobugconsulting.ro> Peter Lemenkov wrote: > 2007/4/2, Ville Skytt? : >> On Monday 02 April 2007, Peter Lemenkov wrote: >> >> > Another one thing I want to mention - is there a way to tell yum to >> > use --excludedocs flag? >> >> echo "%_excludedocs 1" >> /etc/rpm/macros > > OK, I did something similar - I added tsflags=nodocs into /etc/yum.conf > Now I want to now - how could I remove already installed docs > properly? I simply execuyte the following line: > > # rm -rf /usr/share/docs/* > > But I suspect that there is a more smart solution. > for i in $(rpm -qa) ; do rpm -i --replacepkgs --replacefiles --excludedocs $i ;done From Jerry.James at usu.edu Mon Apr 2 14:53:16 2007 From: Jerry.James at usu.edu (Jerry James) Date: Mon, 02 Apr 2007 08:53:16 -0600 Subject: Orphan: Moodle In-Reply-To: <460D8A98.6050106@redhat.com> (Mike McGrath's message of "Fri, 30 Mar 2007 17:09:28 -0500") References: <45F7159D.9020806@redhat.com> <460D8A98.6050106@redhat.com> Message-ID: Mike McGrath , on Fri, 30 Mar 2007 at 17:09:28 -0500 you wrote: > Sure thing, do you already have commit access? I committed my first package, latexmk, last week, so I suppose so. :-) -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From tgl at redhat.com Mon Apr 2 15:29:34 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 02 Apr 2007 11:29:34 -0400 Subject: RPM question: how to split an existing package in two? Message-ID: <10070.1175527774@sss.pgh.pa.us> Per a customer suggestion, I recently separated mysql's client libraries out of the base "mysql" RPM into a new "mysql-libs" RPM. I thought this would be a trivial change, but it seems "yum upgrade" fails to cope: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234712 Would someone slip me a clue on what I did wrong? I suppose I'm lacking some specfile directive, but I dunno what... regards, tom lane From skvidal at linux.duke.edu Mon Apr 2 15:35:17 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 02 Apr 2007 11:35:17 -0400 Subject: RPM question: how to split an existing package in two? In-Reply-To: <10070.1175527774@sss.pgh.pa.us> References: <10070.1175527774@sss.pgh.pa.us> Message-ID: <1175528117.12588.100.camel@cutter> On Mon, 2007-04-02 at 11:29 -0400, Tom Lane wrote: > Per a customer suggestion, I recently separated mysql's client libraries > out of the base "mysql" RPM into a new "mysql-libs" RPM. I thought this > would be a trivial change, but it seems "yum upgrade" fails to cope: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234712 > > Would someone slip me a clue on what I did wrong? I suppose I'm lacking > some specfile directive, but I dunno what... so you're preserving the mysql pkg just splitting some items out of it into mysql-libs? So there's no need for an obsolete. In the above bug, as I mentioned in the comment, was the machine where the problem happened multilib? -sv From blizzard at redhat.com Mon Apr 2 15:41:19 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 02 Apr 2007 11:41:19 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: <1175528479.8865.6.camel@localhost.localdomain> For OLPC our disk image is pretty small, and we're carrying a lot of desktop packages. So we know it's possible to make a device that's in the 250MB disk size range, it's just a question of what you want to include and what functionality you want. The way that our "base" distro is set up makes that hard, though. But we're seeing more and more small devices and lots of them use Fedora. It's just a question of what tools to use to build images. We're using pilgrim: http://git.fedoraproject.org/?p=pilgrim/.git;a=summary which lets us pick a really small subset. It also uses a better initramfs solution that will work on cdroms, usb drives, etc, so you can slap an image onto a cheap usb hdd or flash drive and it can be used there. David Zeuthen did a lot of this work and his posts to the mailing list archives give a good overview, as does the readme: http://git.fedoraproject.org/?p=pilgrim/.git;a=blob;f=README.fedora;h=aa64cfda24576f3cb81b2ab99b2aae0fb0a2b8ae;hb=HEAD --Chris From mattdm at mattdm.org Mon Apr 2 16:11:30 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 2 Apr 2007 12:11:30 -0400 Subject: RPM question: how to split an existing package in two? In-Reply-To: <1175528117.12588.100.camel@cutter> References: <10070.1175527774@sss.pgh.pa.us> <1175528117.12588.100.camel@cutter> Message-ID: <20070402161130.GA15185@jadzia.bu.edu> On Mon, Apr 02, 2007 at 11:35:17AM -0400, seth vidal wrote: > In the above bug, as I mentioned in the comment, was the machine where > the problem happened multilib? This has probably already been hashed through a dozen times, but it seems like it'd help reduce confusion if yum's transaction check error message would include the architectures of the packages in question. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bugs.michael at gmx.net Mon Apr 2 17:14:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 2 Apr 2007 19:14:09 +0200 Subject: RPM question: how to split an existing package in two? In-Reply-To: <1175528117.12588.100.camel@cutter> References: <10070.1175527774@sss.pgh.pa.us> <1175528117.12588.100.camel@cutter> Message-ID: <20070402191409.f0ccdfd0.bugs.michael@gmx.net> On Mon, 02 Apr 2007 11:35:17 -0400, seth vidal wrote: > On Mon, 2007-04-02 at 11:29 -0400, Tom Lane wrote: > > Per a customer suggestion, I recently separated mysql's client libraries > > out of the base "mysql" RPM into a new "mysql-libs" RPM. I thought this > > would be a trivial change, but it seems "yum upgrade" fails to cope: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234712 > > > > Would someone slip me a clue on what I did wrong? I suppose I'm lacking > > some specfile directive, but I dunno what... > > > so you're preserving the mysql pkg just splitting some items out of it > into mysql-libs? > > So there's no need for an obsolete. > > In the above bug, as I mentioned in the comment, was the machine where > the problem happened multilib? Most likely. Because the new "mysql" package is available as x86_64 only, while mysql-libs.i386 and mysql-devel.i386 are available for multi-lib. An old mysql.i386 would not be updated, but would cause conflicts. From opensource at till.name Mon Apr 2 17:22:21 2007 From: opensource at till.name (Till Maas) Date: Mon, 02 Apr 2007 19:22:21 +0200 Subject: How to load a kernel module automatically? In-Reply-To: <200704012127.17543.ville.skytta@iki.fi> References: <460F9046.2020405@gmail.gom> <200704011952.15347.opensource@till.name> <200704012127.17543.ville.skytta@iki.fi> Message-ID: <200704021922.35807.opensource@till.name> On So April 1 2007, Ville Skytt? wrote: > You got it backwards, the simplistic scriptlets posted would do things in > situations where they shouldn't be doing anything (this depends on the > packaging scheme used - I'm assuming you're using the > http://fedoraproject.org/wiki/Packaging/KernelModules one). I only knew the dkms way in more detail, where this should not cause any trouble you described: %post rmmod uinput || : %{_sysconfdir}/sysconf/modules/%{name}.modules || : and with the kmod way something like this (I do not really understand without reading it in detail, how the different kernel flavors are separated, so maybe this has to be done for each variant slightly different) may work: %post if [ "%{kversion}" == "$(uname -r)" ] then rmmod module || : %{_sysconfdir}/sysconf/modules/%{name}.modules || : fi This will only remove and/or load the module , when one for the current kernel is available (which is with the dkms scheme normally the case) and because of no action in %preun, no other harm will caused. But if this causes any other trouble, I would be pleased to be noticed about it. 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 buildsys at fedoraproject.org Mon Apr 2 19:40:26 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 2 Apr 2007 15:40:26 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-02 Message-ID: <20070402194026.412F5152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): cups FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) gpm FC5-updates > FC7 (0:1.20.1-82.fc5 > 0:1.20.1-81.fc7) FC6-updates > FC7 (0:1.20.1-82.fc6 > 0:1.20.1-81.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) peter AT thecodergeek.com: scribes FE6 > FE7 (0:0.3.2-1.fc6 > 0:0.3.1-1.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) shahms AT shahms.com: bzr-gtk FE6 > FE7 (0:0.14.0-1.fc6 > 0:0.13.0-1.fc7) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- bzr-gtk: shahms AT shahms.com FE6 > FE7 (0:0.14.0-1.fc6 > 0:0.13.0-1.fc7) cups: UNKNOWN OWNER (possibly Core package) FC5-updates > FC6-updates (1:1.2.8-1.fc5 > 1:1.2.7-1.8.fc6) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) gpm: UNKNOWN OWNER (possibly Core package) FC5-updates > FC7 (0:1.20.1-82.fc5 > 0:1.20.1-81.fc7) FC6-updates > FC7 (0:1.20.1-82.fc6 > 0:1.20.1-81.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) scribes: peter AT thecodergeek.com FE6 > FE7 (0:0.3.2-1.fc6 > 0:0.3.1-1.fc7) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From lemenkov at gmail.com Mon Apr 2 19:44:51 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Mon, 2 Apr 2007 23:44:51 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: 2007/4/2, Peter Lemenkov : > Even today, then there are a lot of 70-80$ (typical price in Moscow) > 1Gbyte flash-disks there are things that I can't accept. For instance > - we have a grub depending on 8mbyte-sized bulk of funny pictures > called fedora-logos. I saw another strange and very expensive > dependencies but always forget to create a bookmark. I just found another one issue - fedora-release depends on basically useless rpm called fedora-release-notes: [root at dhcppc0 ~]# rpm -e --test fedora-release-notes error: Failed dependencies: fedora-release-notes >= 6 is needed by (installed) fedora-release-6-4.noarch [root at dhcppc0 ~]# Look, I understand that there are some people who like to read eula-hula and other very interesting things that can be easily taken from downloads.fedora.redhat.com or googled but I actually want to get an opportunity not to install them. :) Another one issue is further splitting of packages into sub-packages and modularization. For instance I found useless for me mackage called dbus-python. It contains python bindings for dbus and weights at about 600 kbytes. I can't remove it because smartmontools contains 24 kbytes of python scripts which can be easily placed in something called smartmontools-python. :) -- With best regards! From jkeating at redhat.com Mon Apr 2 19:57:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Apr 2007 15:57:46 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: <200704021557.46684.jkeating@redhat.com> On Monday 02 April 2007 15:44:51 Peter Lemenkov wrote: > Look, I understand that there are some people who like to read > eula-hula and other very interesting things that can be easily taken > from downloads.fedora.redhat.com or googled but I actually want to get > an opportunity not to install them. :) This is here partly for upgrade paths. In the past, the release notes were a part of fedora-release anyway, there was no separation. We split them up so that the Docs folks could work on the notes independently from the fedora-release package. To ensure that notes stayed on the system in the event of upgrades, fedora-release requires the release-notes. That said, for your tiny spin you could make an empty or tiny package that provided fedora-release-notes that just had a single file explaining what the LiveCD was for and all that. You would be able to save a lot of space with that. Of course, then you wouldn't be able to call it Fedora, but then again, I don't want to see something produced as "Fedora" that didn't include our release notes. -- 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 j.w.r.degoede at hhs.nl Mon Apr 2 20:18:49 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Apr 2007 22:18:49 +0200 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704021557.46684.jkeating@redhat.com> References: <200704021557.46684.jkeating@redhat.com> Message-ID: <46116529.9020701@hhs.nl> Jesse Keating wrote: > On Monday 02 April 2007 15:44:51 Peter Lemenkov wrote: >> Look, I understand that there are some people who like to read >> eula-hula and other very interesting things that can be easily taken >> from downloads.fedora.redhat.com or googled but I actually want to get >> an opportunity not to install them. :) > > This is here partly for upgrade paths. In the past, the release notes were a > part of fedora-release anyway, there was no separation. We split them up so > that the Docs folks could work on the notes independently from the > fedora-release package. To ensure that notes stayed on the system in the > event of upgrades, fedora-release requires the release-notes. > > That said, for your tiny spin you could make an empty or tiny package that > provided fedora-release-notes that just had a single file explaining what the > LiveCD was for and all that. You would be able to save a lot of space with > that. Of course, then you wouldn't be able to call it Fedora, but then > again, I don't want to see something produced as "Fedora" that didn't include > our release notes. > Hmm, I understand, but I find this a bit harsh, I actually find Peter's striving for a minimal minimal install a good thing, including the not including 600k of release notes? Can't we have a text only version of them or something like that?? Regards, Hans From lemenkov at gmail.com Mon Apr 2 20:12:25 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 3 Apr 2007 00:12:25 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704021557.46684.jkeating@redhat.com> References: <200704021557.46684.jkeating@redhat.com> Message-ID: > To ensure that notes stayed on the system in the > event of upgrades, fedora-release requires the release-notes. Why it's necessary to *require* fedora-release-notes to be installed? If it would be a completely independent package everyone would be satisfied. -- With best regards! From jkeating at redhat.com Mon Apr 2 20:20:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Apr 2007 16:20:39 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: <200704021557.46684.jkeating@redhat.com> Message-ID: <200704021620.40044.jkeating@redhat.com> On Monday 02 April 2007 16:12:25 Peter Lemenkov wrote: > Why it's necessary to *require* fedora-release-notes to be installed? > If it would be a completely independent package everyone would be > satisfied. As stated, if you came from a Fedora release that didn't have the split out package, you wouldn't get the new release notes upon update, you'd just have your old release notes removed. That and some of us feel that release notes are part of the "Fedora Standard Base", things we're not interested in seeing removed and still having something called Fedora. -- 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 lemenkov at gmail.com Mon Apr 2 20:24:00 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 3 Apr 2007 00:24:00 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704021620.40044.jkeating@redhat.com> References: <200704021557.46684.jkeating@redhat.com> <200704021620.40044.jkeating@redhat.com> Message-ID: > As stated, if you came from a Fedora release that didn't have the split out > package, you wouldn't get the new release notes upon update, you'd just have > your old release notes removed. That and some of us feel that release notes > are part of the "Fedora Standard Base", things we're not interested in seeing > removed and still having something called Fedora. OK, I understand - some kinda politics :) -- With best regards! From mattdm at mattdm.org Mon Apr 2 20:30:14 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 2 Apr 2007 16:30:14 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <46116529.9020701@hhs.nl> References: <200704021557.46684.jkeating@redhat.com> <46116529.9020701@hhs.nl> Message-ID: <20070402203014.GA7483@jadzia.bu.edu> On Mon, Apr 02, 2007 at 10:18:49PM +0200, Hans de Goede wrote: > Hmm, I understand, but I find this a bit harsh, I actually find Peter's > striving for a minimal minimal install a good thing, including the not > including 600k of release notes? Can't we have a text only version of them > or something like that?? Aren't the release notes docs? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From j.w.r.degoede at hhs.nl Mon Apr 2 20:52:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 Apr 2007 22:52:47 +0200 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <20070402203014.GA7483@jadzia.bu.edu> References: <200704021557.46684.jkeating@redhat.com> <46116529.9020701@hhs.nl> <20070402203014.GA7483@jadzia.bu.edu> Message-ID: <46116D1F.4070805@hhs.nl> Matthew Miller wrote: > On Mon, Apr 02, 2007 at 10:18:49PM +0200, Hans de Goede wrote: >> Hmm, I understand, but I find this a bit harsh, I actually find Peter's >> striving for a minimal minimal install a good thing, including the not >> including 600k of release notes? Can't we have a text only version of them >> or something like that?? > > Aren't the release notes docs? > Good point, they should be marked %doc, in which case on a true minimal install without doc instalation they wouldn't take any diskspace. Regards, Hans From jkeating at redhat.com Mon Apr 2 20:47:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Apr 2007 16:47:37 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <46116D1F.4070805@hhs.nl> References: <20070402203014.GA7483@jadzia.bu.edu> <46116D1F.4070805@hhs.nl> Message-ID: <200704021647.37284.jkeating@redhat.com> On Monday 02 April 2007 16:52:47 Hans de Goede wrote: > Matthew Miller wrote: > > On Mon, Apr 02, 2007 at 10:18:49PM +0200, Hans de Goede wrote: > >> Hmm, I understand, but I find this a bit harsh, I actually find Peter's > >> striving for a minimal minimal install a good thing, including the not > >> including 600k of release notes? Can't we have a text only version of > >> them or something like that?? > > > > Aren't the release notes docs? > > Good point, they should be marked %doc, in which case on a true minimal > install without doc instalation they wouldn't take any diskspace. > $ rpm -qd fedora-release-notes |wc -l 104 [jkeating at reducto ~]$ rpm -ql fedora-release-notes |wc -l 152 Most are marked as docs. I haven't looked to see what isn't yet. -- 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 lemenkov at gmail.com Mon Apr 2 21:04:53 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 3 Apr 2007 01:04:53 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704021647.37284.jkeating@redhat.com> References: <20070402203014.GA7483@jadzia.bu.edu> <46116D1F.4070805@hhs.nl> <200704021647.37284.jkeating@redhat.com> Message-ID: > > Good point, they should be marked %doc, in which case on a true minimal > > install without doc instalation they wouldn't take any diskspace. > $ rpm -qd fedora-release-notes |wc -l > 104 > [jkeating at reducto ~]$ rpm -ql fedora-release-notes |wc -l > 152 > > Most are marked as docs. I haven't looked to see what isn't yet. In any case I forced to download entire package then I'm doing "yum update" :) -- With best regards! From stickster at gmail.com Mon Apr 2 23:27:00 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 02 Apr 2007 19:27:00 -0400 Subject: Fedora ICS Schedule Message-ID: <1175556420.16165.32.camel@localhost.localdomain> Is anyone within the sound of this email maintaining the "Fedora 7" calendar on Google? I noticed that the dates haven't shifted to match the wiki schedule. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 stickster at gmail.com Mon Apr 2 23:37:46 2007 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 02 Apr 2007 19:37:46 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704021647.37284.jkeating@redhat.com> References: <20070402203014.GA7483@jadzia.bu.edu> <46116D1F.4070805@hhs.nl> <200704021647.37284.jkeating@redhat.com> Message-ID: <1175557066.16165.37.camel@localhost.localdomain> On Mon, 2007-04-02 at 16:47 -0400, Jesse Keating wrote: > On Monday 02 April 2007 16:52:47 Hans de Goede wrote: > > Matthew Miller wrote: > > > On Mon, Apr 02, 2007 at 10:18:49PM +0200, Hans de Goede wrote: > > >> Hmm, I understand, but I find this a bit harsh, I actually find Peter's > > >> striving for a minimal minimal install a good thing, including the not > > >> including 600k of release notes? Can't we have a text only version of > > >> them or something like that?? > > > > > > Aren't the release notes docs? > > > > Good point, they should be marked %doc, in which case on a true minimal > > install without doc instalation they wouldn't take any diskspace. > > > > $ rpm -qd fedora-release-notes |wc -l > 104 > [jkeating at reducto ~]$ rpm -ql fedora-release-notes |wc -l > 152 > > Most are marked as docs. I haven't looked to see what isn't yet. The scrollkeeper OMFs and the .desktop file for "About Fedora" most likely make up the majority of what isn't marked as docs. Since those aren't going to work without the backing XML/HTML files, perhaps we should just mark the remainder as %doc. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 jwboyer at jdub.homelinux.org Tue Apr 3 00:16:05 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 02 Apr 2007 19:16:05 -0500 Subject: Fedora ICS Schedule In-Reply-To: <1175556420.16165.32.camel@localhost.localdomain> References: <1175556420.16165.32.camel@localhost.localdomain> Message-ID: <1175559365.32658.55.camel@vader.jdub.homelinux.org> On Mon, 2007-04-02 at 19:27 -0400, Paul W. Frields wrote: > Is anyone within the sound of this email maintaining the "Fedora 7" > calendar on Google? I noticed that the dates haven't shifted to match > the wiki schedule. Which? I created one forever ago, but nobody seemed interested so I deleted it... josh From paul at xelerance.com Tue Apr 3 03:29:17 2007 From: paul at xelerance.com (Paul Wouters) Date: Tue, 3 Apr 2007 05:29:17 +0200 (CEST) Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: <20070402203014.GA7483@jadzia.bu.edu> <46116D1F.4070805@hhs.nl> <200704021647.37284.jkeating@redhat.com> Message-ID: On Tue, 3 Apr 2007, Peter Lemenkov wrote: > Subject: Re: Fedora for tiny devices - exessive dependencies > In any case I forced to download entire package then I'm doing "yum update" :) I find the mentioning of "tiny devices" and "yum" together rather..... amusing :) You can't run yum on machines with less then 256MB. Which is rather silly since a lot of my virtual machines now only need that much memory because of yum. Any what I would call "tiny device" would run into the issue of not being able to run the package manager. There are no such problems with apt/dpkg. I am not sure why yum is such a memory hog. I understand it is a cpu hog because unlike apt, it needs to recalculate all the dependancies every time it is invoked, but why does it requires 256MB to operate? Paul From mattdm at mattdm.org Tue Apr 3 03:37:41 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 2 Apr 2007 23:37:41 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: <20070402203014.GA7483@jadzia.bu.edu> <46116D1F.4070805@hhs.nl> <200704021647.37284.jkeating@redhat.com> Message-ID: <20070403033741.GA8230@jadzia.bu.edu> On Tue, Apr 03, 2007 at 05:29:17AM +0200, Paul Wouters wrote: > There are no such problems with apt/dpkg. I am not sure why yum is such a > memory hog. I understand it is a cpu hog because unlike apt, it needs to > recalculate all the dependancies every time it is invoked, but why does it > requires 256MB to operate? Where else would it put all the data it's working on? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From lemenkov at gmail.com Tue Apr 3 05:03:23 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 3 Apr 2007 09:03:23 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: <20070402203014.GA7483@jadzia.bu.edu> <46116D1F.4070805@hhs.nl> <200704021647.37284.jkeating@redhat.com> Message-ID: > I find the mentioning of "tiny devices" and "yum" together rather..... amusing :) > > You can't run yum on machines with less then 256MB. Which is rather silly since > a lot of my virtual machines now only need that much memory because of yum. Any > what I would call "tiny device" would run into the issue of not being able to > run the package manager. Actually my tiny device is not so tiny - it has more than 1GB of RAM so this is not a problem ) -- With best regards! From lemenkov at gmail.com Tue Apr 3 05:07:54 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 3 Apr 2007 09:07:54 +0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: > Is anyone interested in using Fedora Core as a (for example) > file-server? It was really upset me then I discovered that a typical > installation (NFS, SAMBA, ftp and administrative tools), can't be > fitted onto a 128- or 256-mbyte-sized partition (inexpensive > flash-disk). I found another one thing that eats my HDD - different locales. We got a way not to install docs, maybe there is a way not to install zillion of different locales? [root at dhcppc0 ~]# du -hs /usr/share/locale 40M /usr/share/locale -- With best regards! From bugs.michael at gmx.net Tue Apr 3 08:07:42 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 3 Apr 2007 10:07:42 +0200 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: Message-ID: <20070403100742.87c0bfa6.bugs.michael@gmx.net> On Tue, 3 Apr 2007 09:07:54 +0400, Peter Lemenkov wrote: > I found another one thing that eats my HDD - different locales. We got > a way not to install docs, maybe there is a way not to install zillion > of different locales? > > [root at dhcppc0 ~]# du -hs /usr/share/locale > 40M /usr/share/locale > Install/replace packages with %_install_langs defined like this: rpm -Uvh --replacepkgs --define '_install_langs en,de,it' ... From dennis at ausil.us Tue Apr 3 14:24:06 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 3 Apr 2007 09:24:06 -0500 Subject: CVS/Buildsys Downtime Message-ID: <200704030924.07004.dennis@ausil.us> Hey everyone, sorry for the short notice. CVS and all buildsystems will be unavailable Friday 6th April - Sunday 8th April. hopefully we will be done on Saturday but want to ensure that everything is up and running and right. This is so that we can merge Core and Extras cvs together along with the merge will be a new buildsys koji. koji's source is at https://hosted.fedoraproject.org/projects/koji it offers us much more flexibility than plague. koji has a web interface at http://koji.fedoraproject.org/koji/ This is the final piece to having a merged fedora. Thank you in advance for your patience and understanding. -- Dennis Gilmore, RHCE From jkeating at redhat.com Tue Apr 3 14:34:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Apr 2007 10:34:36 -0400 Subject: CVS/Buildsys Downtime In-Reply-To: <200704030924.07004.dennis@ausil.us> References: <200704030924.07004.dennis@ausil.us> Message-ID: <200704031034.39915.jkeating@redhat.com> On Tuesday 03 April 2007 10:24:06 Dennis Gilmore wrote: > koji's source is at https://hosted.fedoraproject.org/projects/koji ?it > offers us much more flexibility than plague. koji has a web interface at > http://koji.fedoraproject.org/koji/ > > This is the final piece to having a merged fedora. ?Thank you in advance > for your patience and understanding. We've had a test instance of koji running for a short while, I hope to enable more public testing of it today through this week. Koji packages did land in Extras yesterday, and we're going to add a script to use existing plague setups to set up koji too. I'll post more when we're ready for wider testing. -- 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 bpepple at fedoraproject.org Tue Apr 3 14:28:31 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 03 Apr 2007 10:28:31 -0400 Subject: FESCo Meeting Summary for 2007-03-22 Message-ID: <1175610511.22450.12.camel@lincoln> Whoops, sorry about the delay on sending this out to the mailing lists. Wrote this up last week, but forgot to actually send this out. === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jesse Keating (f13) * Warren Togami (warren) * Tom Callaway (spot) * Josh Boyer (jwb) * Jeremy Katz (jeremy) === Absent === * Bill Nottingham (notting) == Summary == === Core Review Process === * Discussed making the Core Review a blocker for F8. === Package Database ==== * abadger1999 is close to finishing the PackageDB. === Broken Upgrade Paths === * Solutions for dealing with broken upgrade paths was discussed. One solution might be to have the QA team monitor this. === Packaging Committee Report === * FESCo approved the Packaging Committee's guidelines regarding: * http://fedoraproject.org/wiki/PackagingDrafts/cmake === Misc ==== * Will move the Packaging Committee report to the beginning of FESCo meetings, so that people interested in this don't need to sit through the whole meeting to get to this item. * Discussed whether Ruby Gems should be allowed in Fedora. More information is needed before a decision can be made. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070322 Thanks. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 bpepple at fedoraproject.org Tue Apr 3 14:32:23 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 03 Apr 2007 10:32:23 -0400 Subject: FESCo Meeting Summary for 2007-03-29 Message-ID: <1175610743.22450.17.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * Josh Boyer (jwb) * Jeremy Katz (jeremy) === Absent === * Jesse Keating (f13) * Tom Callaway (spot) * Bill Nottingham (notting) == Summary == === Packaging Committee Report === * FESCo approved the Packaging Committee's guidelines regarding: * http://fedoraproject.org/wiki/PackagingDrafts/PostRelease * http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros * http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames === EPEL === * FESCo approved the formation of a steering committee for EPEL. http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee === Feature Freeze Policy === * FESCo approved the Feature Freeze Policy. jeremy will send an e-mail regarding this to the appropriate lists. http://fedoraproject.org/wiki/Releases/FeatureFreezePolicy === Sponsor Nominations === * David Lutterkort was nominated and accepted as a new sponsor. === cvs-import changes === * Jens Petersen's patch will be applied to the current cvs-import script. === Retired Package Policy === * Discussed possible solutions for this, but didn't come to a resolution. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070329 Thanks. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 Tue Apr 3 17:21:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Apr 2007 13:21:22 -0400 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <45FAFE2E.8040304@redhat.com> References: <45FAFE2E.8040304@redhat.com> Message-ID: <200704031321.22723.jkeating@redhat.com> On Friday 16 March 2007 16:29:34 Thomas Fitzsimmons wrote: > I'd like to propose the following packages for exclusion from Fedora 7: > > java-1.4.2-gcj-compat What is the status of this? Is there anything left needing it? -- 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 blizzard at redhat.com Tue Apr 3 17:37:16 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 03 Apr 2007 13:37:16 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: References: <200704021557.46684.jkeating@redhat.com> Message-ID: <1175621836.3257.23.camel@localhost.localdomain> On Tue, 2007-04-03 at 00:12 +0400, Peter Lemenkov wrote: > > To ensure that notes stayed on the system in the > > event of upgrades, fedora-release requires the release-notes. > > Why it's necessary to *require* fedora-release-notes to be installed? > If it would be a completely independent package everyone would be > satisfied. > Our how about the fact that grub pulls in the fedora icons set which is _huge_? --Chris From jkeating at redhat.com Tue Apr 3 17:49:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Apr 2007 13:49:42 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <1175621836.3257.23.camel@localhost.localdomain> References: <1175621836.3257.23.camel@localhost.localdomain> Message-ID: <200704031349.42466.jkeating@redhat.com> On Tuesday 03 April 2007 13:37:16 Christopher Blizzard wrote: > Our how about the fact that grub pulls in the fedora icons set which is > _huge_? Because grub uses a Fedora icon. And we have some history desire to keep all trademarked things in one package for easy replacement. -- 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 blizzard at redhat.com Tue Apr 3 18:00:01 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 03 Apr 2007 14:00:01 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704031349.42466.jkeating@redhat.com> References: <1175621836.3257.23.camel@localhost.localdomain> <200704031349.42466.jkeating@redhat.com> Message-ID: <1175623201.3257.25.camel@localhost.localdomain> On Tue, 2007-04-03 at 13:49 -0400, Jesse Keating wrote: > On Tuesday 03 April 2007 13:37:16 Christopher Blizzard wrote: > > Our how about the fact that grub pulls in the fedora icons set which is > > _huge_? > > Because grub uses a Fedora icon. And we have some history desire to keep all > trademarked things in one package for easy replacement. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers I think that we forked it and fixed it, though. It requires "system-logos" now. --Chris From fitzsim at redhat.com Tue Apr 3 18:29:47 2007 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Tue, 03 Apr 2007 14:29:47 -0400 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <200704031321.22723.jkeating@redhat.com> References: <45FAFE2E.8040304@redhat.com> <200704031321.22723.jkeating@redhat.com> Message-ID: <46129D1B.1040709@redhat.com> Jesse Keating wrote: > On Friday 16 March 2007 16:29:34 Thomas Fitzsimmons wrote: >> I'd like to propose the following packages for exclusion from Fedora 7: >> >> java-1.4.2-gcj-compat > > What is the status of this? Is there anything left needing it? csound is fixed in CVS but can't be rebuilt for an unrelated reason, but the currently-built package's dependencies will be satisfied by java-1.5.0-gcj's compatibility virtual provides. It turns out that mockobjects requires java-devel < 1.5, however, mockobjects is not needed by anything in Core or Extras, so I'm proposing that it be removed for Fedora 7 (though it's not listed in comps-fc7.xml.in). If it is needed in the future, we can add jMock 2, which requires Java >= 1.5. I've made sure that all other packages that had requirements on java-1.4.2-gcj-compat*, gnu-crypto*, jessie and gjdoc have been updated to java-1.5.0-gcj* and sinjdoc. My comps-fc7.xml.in patch has also been applied. Now I have to make java-1.5.0-gcj obsolete gnu-crypto and jessie and make sinjdoc obsolete gjdoc. Tom From mattdm at mattdm.org Tue Apr 3 18:30:38 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 3 Apr 2007 14:30:38 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704031349.42466.jkeating@redhat.com> References: <1175621836.3257.23.camel@localhost.localdomain> <200704031349.42466.jkeating@redhat.com> Message-ID: <20070403183038.GA32529@jadzia.bu.edu> On Tue, Apr 03, 2007 at 01:49:42PM -0400, Jesse Keating wrote: > > Our how about the fact that grub pulls in the fedora icons set which is > > _huge_? > Because grub uses a Fedora icon. And we have some history desire to keep > all trademarked things in one package for easy replacement. Subpackages might be the answer here -- having everything in one src.rpm is hugely helpful, but I don't think there's a need to restrict to one resultant RPM. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Tue Apr 3 18:34:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 3 Apr 2007 14:34:29 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <20070403183038.GA32529@jadzia.bu.edu> References: <200704031349.42466.jkeating@redhat.com> <20070403183038.GA32529@jadzia.bu.edu> Message-ID: <200704031434.29906.jkeating@redhat.com> On Tuesday 03 April 2007 14:30:38 Matthew Miller wrote: > Subpackages might be the answer here -- having everything in one src.rpm is > hugely helpful, but I don't think there's a need to restrict to one > resultant RPM. The compose tools work on the rpms level, not the srpms. -- 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 3 18:52:56 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 3 Apr 2007 14:52:56 -0400 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704031434.29906.jkeating@redhat.com> References: <200704031349.42466.jkeating@redhat.com> <20070403183038.GA32529@jadzia.bu.edu> <200704031434.29906.jkeating@redhat.com> Message-ID: <20070403185256.GA1696@jadzia.bu.edu> On Tue, Apr 03, 2007 at 02:34:29PM -0400, Jesse Keating wrote: > > Subpackages might be the answer here -- having everything in one src.rpm is > > hugely helpful, but I don't think there's a need to restrict to one > > resultant RPM. > The compose tools work on the rpms level, not the srpms. Oh, right; I'm thinking at a more global (CentOS, BU Linux) level. So at the composed-non-Fedora level, which inconvenience would people prefer? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From peter at thecodergeek.com Wed Apr 4 07:06:00 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 04 Apr 2007 00:06:00 -0700 Subject: CVS/Buildsys Downtime In-Reply-To: <200704030924.07004.dennis@ausil.us> References: <200704030924.07004.dennis@ausil.us> Message-ID: <1175670360.7729.2.camel@tuxhugs> Let me be the first to say: Heck Yes! Thank you *very* much for the hard work you and Mike McGrath and Seth Vidal and everyone else on the infrastructure team do for us. <3 -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 4 08:26:40 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 Apr 2007 10:26:40 +0200 Subject: Fedora for tiny devices - exessive dependencies In-Reply-To: <200704031434.29906.jkeating@redhat.com> References: <200704031349.42466.jkeating@redhat.com> <20070403183038.GA32529@jadzia.bu.edu> <200704031434.29906.jkeating@redhat.com> Message-ID: <20070404102640.40bb7cb1@python3.es.egwn.lan> Jesse Keating wrote : > On Tuesday 03 April 2007 14:30:38 Matthew Miller wrote: > > Subpackages might be the answer here -- having everything in one src.rpm is > > hugely helpful, but I don't think there's a need to restrict to one > > resultant RPM. > > The compose tools work on the rpms level, not the srpms. But they also take care of dependencies properly, right? We could easily have the "fedora-logos" srpm creating many different rpms, of which one would be for instance "fedora-logos-grub" providing "system-logos-grub" and containing only the images grub requires, thus not pulling in all of the huge backgrounds, splash screens etc. on minimal systems. Things would just work. I think this is what Matthew meant ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 0.12 0.31 0.45 From belegdol at gmail.com Wed Apr 4 11:24:46 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 04 Apr 2007 13:24:46 +0200 Subject: How to load a kernel module automatically? In-Reply-To: <200704012110.32881.ville.skytta@iki.fi> References: <460F9046.2020405@gmail.gom> <200704011836.43268.ville.skytta@iki.fi> <460FEF26.1000607@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> Message-ID: <46138AFE.50909@gmail.gom> Ville Skytt? napisa?(a): > > When taking everything that needs to be taken into account, the scriptlets get > more than a little hairy. My previous mail scratches the surface of > packaging related problems with it. Further things to consider: Can you be > sure that removing a module won't screw the runtime system's state some way > (for example, for practical purposes, some hardware which may be essential to > the user (which you as the packager can't know) can disappear on the fly, > just like that)? And what do you do if the module removal fails on package > upgrades? What if it fails on package erase time? Removal of module should not render the system unusable, because you can always log-in with password if the reader does not work for one reason o another. Getting back to scriptlets: you mean that I should add depmod -a on %post and depmod -e on %preun? I would like the upgrade to be as painless for users as possible, and as there is no easy way to give them a message like "add uinput to modprobe.conf", they could be a bit surprised when swiping will cease to work for them. From buildsys at fedoraproject.org Wed Apr 4 11:32:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 4 Apr 2007 07:32:07 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-04 Message-ID: <20070404113207.BD9E9152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) shahms AT shahms.com: bzrtools FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- bzrtools: shahms AT shahms.com FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From ville.skytta at iki.fi Wed Apr 4 12:05:00 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 4 Apr 2007 15:05:00 +0300 Subject: How to load a kernel module automatically? In-Reply-To: <46138AFE.50909@gmail.gom> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> Message-ID: <200704041505.00482.ville.skytta@iki.fi> On Wednesday 04 April 2007, Julian Sikorski wrote: > Removal of module should not render the system unusable, [...] Famous last words :) > Getting back to scriptlets: you mean that I should add depmod > -a on %post and depmod -e on %preun? I suggest you read through http://fedoraproject.org/wiki/Packaging/KernelModules and apply ideas presented there to the module packaging scheme you're using in case you're not going to use that one as is. > I would like the upgrade to be as > painless for users as possible, and as there is no easy way to give them > a message like "add uinput to modprobe.conf", I don't think that would be necessary. Just drop in the /etc/sysconfig/modules snippet, run appropriate depmods and be done with it. What I was objecting to was explicitly installing/removing modules in/from the running kernel in package scriptlets. > they could be a bit surprised when swiping will cease to work for them. I fail to see how not installing/removing modules in %post and friends would result in that. In fact it feels more likely that it could happen if you *do* it. From belegdol at gmail.com Wed Apr 4 12:18:22 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Wed, 04 Apr 2007 14:18:22 +0200 Subject: How to load a kernel module automatically? In-Reply-To: <200704041505.00482.ville.skytta@iki.fi> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> Message-ID: <4613978E.8080302@gmail.gom> Ville Skytt? napisa?(a): >> Getting back to scriptlets: you mean that I should add depmod >> -a on %post and depmod -e on %preun? > > I suggest you read through > http://fedoraproject.org/wiki/Packaging/KernelModules and apply ideas > presented there to the module packaging scheme you're using in case you're > not going to use that one as is. I guess I will need to use some wildcards for a module present in vanilla kernel. > >> I would like the upgrade to be as >> painless for users as possible, and as there is no easy way to give them >> a message like "add uinput to modprobe.conf", > > I don't think that would be necessary. Just drop in > the /etc/sysconfig/modules snippet, run appropriate depmods and be done with > it. What I was objecting to was explicitly installing/removing modules > in/from the running kernel in package scriptlets. > >> they could be a bit surprised when swiping will cease to work for them. > > I fail to see how not installing/removing modules in %post and friends would > result in that. In fact it feels more likely that it could happen if you > *do* it. What I meant is that the older version did not require uinput at all, so upgrading ignoring the problem will leave users somehow stranded. Thanks for all the info, I'll try to take a look at the package later on (we are at the feature freeze anyway). From bpepple at fedoraproject.org Thu Apr 5 00:03:25 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 04 Apr 2007 20:03:25 -0400 Subject: Plan for tomorrows (20070405) FESCO meeting Message-ID: <1175731405.28653.7.camel@lincoln> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- Core Package Review Process -- warren /topic FESCO-Meeting -- new sponsor nominations anyone? /topic FESCO-Meeting -- MISC -- cvs-import changes - has Jens patch been applied? /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- Extras 7 preparation - nirik? /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- EPEL /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 sundaram at fedoraproject.org Thu Apr 5 01:17:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 05 Apr 2007 06:47:26 +0530 Subject: Plan for tomorrows (20070405) FESCO meeting In-Reply-To: <1175731405.28653.7.camel@lincoln> References: <1175731405.28653.7.camel@lincoln> Message-ID: <46144E26.7080504@fedoraproject.org> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, > rdieter, tibbs, scop > > /topic FESCO-Meeting -- Core Package Review Process -- warren > > /topic FESCO-Meeting -- new sponsor nominations anyone? > > /topic FESCO-Meeting -- MISC -- cvs-import changes - has Jens patch been > applied? > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-Meeting -- MISC -- Extras 7 preparation - nirik? > > /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb > > /topic FESCO-Meeting -- EPEL > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). Do consider adding Packaging Conflicts to the topics. The number of packaging conflicts are way higher than necessary. It probably someone/a team to retroactively review, clean up all the existing packages, form guidelines to avoid conflicts and add a check on the QA review too to avoid this on future packages. https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00017.html Rahul From a.badger at gmail.com Thu Apr 5 02:12:48 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 04 Apr 2007 19:12:48 -0700 Subject: Fedora Account System Changes Message-ID: <1175739168.30064.38.camel@localhost.localdomain> Hi all, As discussed for the past couple weeks here and within fedora infrastructure, we've been working on a few related enhancements to the Fedora Account system. Today we enabled code that does two things: 1) When you are approved for cvsextras, you are automatically approved for fedorabugs. This means that once you have the ability to commit to Fedora CVS you gain the ability to make changes to bug reports in bugzilla. This is the policy we've had for quite a long time but formerly it required users to request membership in the second group and find someone to add them. Note that we haven't yet made a pass through cvsextras to add everyone there to fedorabugs so if you don't have fedorabugs but do have commit access to the repository, go ahead and request membership as you would have in the past. 2) Since Red Hat legal has decided that Red Hat employees have the equivalent of signing the CLA because of the terms of their employment, we needed to restructure the cla_done group to show whether a person has passed the CLA barrier by signing the Fedora Individual Contributor License Agreement (and thus is a member of cla_done until/unless they revoke it) or by being employed by a company that's signed a corporate CLA (in which case cla_done would be dropped when the person is no longer an employee.) We implemented this by creating new groups for each class of CLA. People who've signed the Fedora CLA are now members of cla_fedora. Employees of Red Hat are in cla_redhat. Dell employees (which has a similar corporate CLA to cover employees contributing to Fedora) are covered by cla_dell. Membership in any of these groups automatically grants cla_done so existing code that looks at whether someone is in cla_done will continue to function. If you notice any bugs in the account system feel free to send mail to fedora-infrastructure about it or find someone on #fedora-admin and we'll fix things up. Thanks, -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 tibbs at math.uh.edu Thu Apr 5 02:45:41 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Apr 2007 21:45:41 -0500 Subject: Plan for tomorrows (20070405) FESCO meeting In-Reply-To: <46144E26.7080504@fedoraproject.org> References: <1175731405.28653.7.camel@lincoln> <46144E26.7080504@fedoraproject.org> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> Do consider adding Packaging Conflicts to the topics. Also note http://fedoraproject.org/wiki/PackagingDrafts/Conflicts Discussion in the last PC meeting in January (http://fedoraproject.org/wiki/Packaging/IRCLog20070130) indicates that this draft was approved by PC and FESCo. I am not sure why I can't seem to find it in the guidelines. - J< From tibbs at math.uh.edu Thu Apr 5 04:10:24 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Apr 2007 23:10:24 -0500 Subject: Summary of the 2007-04-03 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-04-03 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070403 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Modifications to the Naming Guidelines for handling non-numeric post-releases: http://fedoraproject.org/wiki/PackagingDrafts/PostRelease * Mandating that filenames in RPMs be utf8: http://fedoraproject.org/wiki/PackagingDrafts/Utf8Filenames * Additional dist-related macros: http://fedoraproject.org/wiki/PackagingDrafts/ExtraDistTagConditionalMacros * Note that redhat-rpm-config is being updated to provide these macros. Currently the F7 version has them. No issues are submitted to FESCO for ratification this week. Misc business: * The issue of noarch packages which are not intended for all architectures was raised. A draft is being written and everyone is urged to contribute. - J< From fedora at leemhuis.info Thu Apr 5 04:49:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Apr 2007 06:49:05 +0200 Subject: Plan for tomorrows (20070405) FESCO meeting In-Reply-To: References: <1175731405.28653.7.camel@lincoln> <46144E26.7080504@fedoraproject.org> Message-ID: <46147FC1.3050805@leemhuis.info> On 05.04.2007 04:45, Jason L Tibbitts III wrote: >>>>>> "RS" == Rahul Sundaram writes: > RS> Do consider adding Packaging Conflicts to the topics. > Also note http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > Discussion in the last PC meeting in January > (http://fedoraproject.org/wiki/Packaging/IRCLog20070130) indicates > that this draft was approved by PC and FESCo. I am not sure why I > can't seem to find it in the guidelines. I asked that two or three times in the past, too, without getting a reply :-( Further: Having a guideline doesn't solve the problem. Someone needs to enforce it. And that's FESCo's job afaics. CU thl From mbacovsk at redhat.com Thu Apr 5 09:25:06 2007 From: mbacovsk at redhat.com (Martin Bacovsky) Date: Thu, 05 Apr 2007 11:25:06 +0200 Subject: Specspo questions Message-ID: <4614C072.6060700@redhat.com> Hi, I'm maintainer of specspo package. I want to generate new po catalogue for translation and have some questions. Current process looks now like this: - generate new po catalgue from selected rpm repos (usually rawhide-nightly) - commit the changes on ELVIS cvs tree - translation team hard-work here - after they commit their changes put everything to tarball and update specspo on DIST with it - wait till next release (FC or RHEL) and goto 1 This shows we have currently just one specspo ELVIS upstream for everything we release. This specspo includes everything I decide to include according to what we are about to release. Problems: - it is not possible to regenerate catalogues for recent release. If package descr or summary changes for recent product we are not able to do the translation (or at least I don't know how) - upstream on ELVIS is not updated, it is recreated from scratch (from different sources) - this can make troubles to translation team (?) - we have one specspo for everything (this can contain a lot of packages not included in dist). Questions: - should specspo contain every package we produce or we should make specspo with just packages included in dist? (cvs branches for different releases on elvis can help) - where can I get list of packages included in release? - should we include all extras packages? Any comment or idea would be appreciated. Regards, Martin From buildsys at fedoraproject.org Thu Apr 5 12:06:11 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 5 Apr 2007 08:06:11 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-05 Message-ID: <20070405120611.CDE8D152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) shahms AT shahms.com: bzrtools FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) stickster AT gmail.com: xmldiff FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- bzrtools: shahms AT shahms.com FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-8.fc5.2 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-8.fc6 > 0:20061119-7.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) xmldiff: stickster AT gmail.com FE5 > FE7 (0:0.6.8-1.fc5 > 0:0.6.7-12.fc6) FE6 > FE7 (0:0.6.8-1.fc6 > 0:0.6.7-12.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From wtogami at redhat.com Thu Apr 5 15:38:48 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 05 Apr 2007 11:38:48 -0400 Subject: Rename cvsextras to packager Message-ID: <46151808.9010606@redhat.com> The name 'cvsextras' is confusing. We should rename it to something like 'packager' which reflects the actual purpose of the group. We should discuss this during today's FESCO meeting. Warren Togami wtogami at redhat.com From bpepple at fedoraproject.org Thu Apr 5 16:01:00 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 05 Apr 2007 12:01:00 -0400 Subject: Rename cvsextras to packager In-Reply-To: <46151808.9010606@redhat.com> References: <46151808.9010606@redhat.com> Message-ID: <1175788860.13917.4.camel@lincoln> On Thu, 2007-04-05 at 11:38 -0400, Warren Togami wrote: > The name 'cvsextras' is confusing. We should rename it to something > like 'packager' which reflects the actual purpose of the group. > > We should discuss this during today's FESCO meeting. Agreed. I'll add it to the schedule. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 chris.stone at gmail.com Thu Apr 5 16:28:26 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 5 Apr 2007 09:28:26 -0700 Subject: Mock builds borked for libgl Message-ID: No matter what I try, mirrorlists, baseurls, autocache, noautocache, I keep getting the following error when trying to build my package with mock: Error: Missing Dependency: mesa-libGL = 6.5.1-7.fc6 is needed by package mesa-libGL-devel I have put my root.log up for the world here: http://tkmame.retrogames.com/fedora-extras/root.log And AFAICT, 6.5.1-9 is the latest so I don't know why it wants the -7 release. Can someone please look into this please? It's been like this for several days now, I was hoping it would just fix itself. :( From wtogami at redhat.com Thu Apr 5 18:23:52 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 05 Apr 2007 14:23:52 -0400 Subject: Rename cvsextras to packager In-Reply-To: <1175788860.13917.4.camel@lincoln> References: <46151808.9010606@redhat.com> <1175788860.13917.4.camel@lincoln> Message-ID: <46153EB8.5010502@redhat.com> Brian Pepple wrote: > On Thu, 2007-04-05 at 11:38 -0400, Warren Togami wrote: >> The name 'cvsextras' is confusing. We should rename it to something >> like 'packager' which reflects the actual purpose of the group. >> >> We should discuss this during today's FESCO meeting. > > Agreed. I'll add it to the schedule. > Agreement during the FESCO meeting today is to delay renaming this, in order to avoid changing too many things at once. Warren From jkeating at redhat.com Thu Apr 5 19:07:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Apr 2007 15:07:34 -0400 Subject: Wiki outage Message-ID: <200704051507.34608.jkeating@redhat.com> We're experiencing some technical difficulties with the systems serving the wiki. It is temporarily unavailable. -- 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 laroche at redhat.com Thu Apr 5 19:15:43 2007 From: laroche at redhat.com (Florian La Roche) Date: Thu, 5 Apr 2007 21:15:43 +0200 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <46129D1B.1040709@redhat.com> References: <45FAFE2E.8040304@redhat.com> <200704031321.22723.jkeating@redhat.com> <46129D1B.1040709@redhat.com> Message-ID: <20070405191543.GA8149@dudweiler.stuttgart.redhat.com> On Tue, Apr 03, 2007 at 02:29:47PM -0400, Thomas Fitzsimmons wrote: > Jesse Keating wrote: > >On Friday 16 March 2007 16:29:34 Thomas Fitzsimmons wrote: > >>I'd like to propose the following packages for exclusion from Fedora 7: > >> > >>java-1.4.2-gcj-compat > > > >What is the status of this? Is there anything left needing it? > > csound is fixed in CVS but can't be rebuilt for an unrelated reason, but > the currently-built package's dependencies will be satisfied by > java-1.5.0-gcj's compatibility virtual provides. > > It turns out that mockobjects requires java-devel < 1.5, however, > mockobjects is not needed by anything in Core or Extras, so I'm proposing > that it be removed for Fedora 7 (though it's not listed in > comps-fc7.xml.in). If it is needed in the future, we can add jMock 2, > which requires Java >= 1.5. > > I've made sure that all other packages that had requirements on > java-1.4.2-gcj-compat*, gnu-crypto*, jessie and gjdoc have been updated to > java-1.5.0-gcj* and sinjdoc. My comps-fc7.xml.in patch has also been > applied. Now I have to make java-1.5.0-gcj obsolete gnu-crypto and jessie > and make sinjdoc obsolete gjdoc. I get this on checking the current FC-devel tree, so probably these all should be removed now: gjdoc-0.7.7-14.fc7.i386.rpm is obsoleted by sinjdoc-0.5-4.fc7.i386.rpm gnu-crypto-2.1.0-2jpp.1.i386.rpm is obsoleted by java-1.5.0-gcj-1.5.0.0-12.fc7.i386.rpm gnu-crypto-javadoc-2.1.0-2jpp.1.i386.rpm is obsoleted by java-1.5.0-gcj-javadoc-1.5.0.0-12.fc7.i386.rpm gnu-crypto-sasl-jdk1.4-2.1.0-2jpp.1.i386.rpm is obsoleted by java-1.5.0-gcj-1.5.0.0-12.fc7.i386.rpm java-1.4.2-gcj-compat-1.4.2.0-40jpp.111.i386.rpm is obsoleted by java-1.5.0-gcj-1.5.0.0-12.fc7.i386.rpm java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp.111.i386.rpm is obsoleted by java-1.5.0-gcj-devel-1.5.0.0-12.fc7.i386.rpm java-1.4.2-gcj-compat-javadoc-1.4.2.0-40jpp.111.i386.rpm is obsoleted by java-1.5.0-gcj-javadoc-1.5.0.0-12.fc7.i386.rpm java-1.4.2-gcj-compat-src-1.4.2.0-40jpp.111.i386.rpm is obsoleted by java-1.5.0-gcj-src-1.5.0.0-12.fc7.i386.rpm jessie-1.0.1-7.i386.rpm is obsoleted by java-1.5.0-gcj-1.5.0.0-12.fc7.i386.rpm mockobjects-alt-jdk1.4-0.09-14jpp.3.i386.rpm did not find a package for: (java-devel < 1.5) mockobjects-jdk1.4-0.09-14jpp.3.i386.rpm did not find a package for: (java-devel < 1.5) regards, Florian La Roche From jkeating at redhat.com Thu Apr 5 19:26:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Apr 2007 15:26:45 -0400 Subject: Wiki outage In-Reply-To: <200704051507.34608.jkeating@redhat.com> References: <200704051507.34608.jkeating@redhat.com> Message-ID: <200704051526.46027.jkeating@redhat.com> On Thursday 05 April 2007 15:07:34 Jesse Keating wrote: > We're experiencing some technical difficulties with the systems serving the > wiki. ?It is temporarily unavailable. And we should be back up again. -- 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 Thu Apr 5 19:29:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Apr 2007 15:29:08 -0400 Subject: Proposing for removal: java-1.4.2-gcj-compat, jessie, gnu-crypto, gjdoc In-Reply-To: <46129D1B.1040709@redhat.com> References: <45FAFE2E.8040304@redhat.com> <200704031321.22723.jkeating@redhat.com> <46129D1B.1040709@redhat.com> Message-ID: <200704051529.08809.jkeating@redhat.com> On Tuesday 03 April 2007 14:29:47 Thomas Fitzsimmons wrote: > csound is fixed in CVS but can't be rebuilt for an unrelated reason, but > the currently-built package's dependencies will be satisfied by > java-1.5.0-gcj's compatibility virtual provides. > > It turns out that mockobjects requires java-devel < 1.5, however, > mockobjects is not needed by anything in Core or Extras, so I'm proposing > that it be removed for Fedora 7 (though it's not listed in > comps-fc7.xml.in). ?If it is needed in the future, we can add jMock 2, > which requires Java >= 1.5. > > I've made sure that all other packages that had requirements on > java-1.4.2-gcj-compat*, gnu-crypto*, jessie and gjdoc have been updated to > java-1.5.0-gcj* and sinjdoc. ?My comps-fc7.xml.in patch has also been > applied. Now I have to make java-1.5.0-gcj obsolete gnu-crypto and jessie > and make sinjdoc obsolete gjdoc. java-1.4.2-gcj-compat jessie gnu-crypto gjdoc mockobjects all blocked from f7. -- 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 FamilleCollet.com Thu Apr 5 19:46:41 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Thu, 05 Apr 2007 21:46:41 +0200 Subject: Mock builds borked for libgl In-Reply-To: References: Message-ID: <46155221.5030905@FamilleCollet.com> Christopher Stone a ?crit : > > Error: Missing Dependency: mesa-libGL = 6.5.1-7.fc6 is needed by > package mesa-libGL-devel > > And AFAICT, 6.5.1-9 is the latest so I don't know why it wants the -7 > release. > > Can someone please look into this please? It's been like this for > several days now, I was hoping it would just fix itself. :( > > Same issue for me, with another lib. Error: Missing Dependency: glib2 = 2.12.3-2.fc6 is needed by package glib2-devel Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from core. Running with yum debuglvel=9 give more information When Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fc6/root resolvedep 'glib2-devel >= 2.0.3' ... Searching pkgSack for dep: glib2-devel Potential match for glib2-devel from glib2-devel - 2.12.3-2.fc6.i386 Matched glib2-devel - 2.12.3-2.fc6.i386 to require for glib2-devel Potential match for glib2-devel from glib2-devel - 2.12.9-1.fc6.i386 Matched glib2-devel - 2.12.9-1.fc6.i386 to require for glib2-devel 0:glib2-devel-2.12.9-1.fc6.i386 That's seems OK But when Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fc6/root install 'glib2-devel >= 2.0.3' ... Searching pkgSack for dep: glib2-devel Potential match for glib2-devel from glib2-devel - 2.12.3-2.fc6.i386 Matched glib2-devel - 2.12.3-2.fc6.i386 to require for glib2-devel Potential match for glib2-devel from glib2-devel - 2.12.9-1.fc6.i386 Matched glib2-devel - 2.12.9-1.fc6.i386 to require for glib2-devel No other glib2-devel installed, adding to list for potential install Solving package glib2-devel - 2.12.3-2.fc6.i386 is installable, not going through the rest This occurs when building from FC6 x86_64. Full (very big) log : http://remi.collet.free.fr/files/root.log Thanks for help. From jkeating at redhat.com Thu Apr 5 20:40:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Apr 2007 16:40:14 -0400 Subject: New mirror layout for the merged core and extras Message-ID: <200704051640.14557.jkeating@redhat.com> I've tossed together a quick rundown of a new mirror layout for the merged core and extras. You can find it here: http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge#head-d370223ce90e602f6d5c4bf3584bd20800da68b6 Any feedback would be appreciated. This could be expected to go live as early as Monday Apr 9th. -- 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 roland at redhat.com Thu Apr 5 20:47:12 2007 From: roland at redhat.com (Roland McGrath) Date: Thu, 5 Apr 2007 13:47:12 -0700 (PDT) Subject: New mirror layout for the merged core and extras In-Reply-To: Jesse Keating's message of Thursday, 5 April 2007 16:40:14 -0400 <200704051640.14557.jkeating@redhat.com> Message-ID: <20070405204712.766DE180055@magilla.sf.frob.com> The final tree picture on the page shows all of: core/development development extras/development are those supposed to be: core/development -> ../development development extras/development -> ../development ? Or else, what does it mean? We're not going to have both merged and unmerged copies of all the development/ contents on mirrors are we? From jkeating at redhat.com Thu Apr 5 20:59:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 5 Apr 2007 16:59:59 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <20070405204712.766DE180055@magilla.sf.frob.com> References: <20070405204712.766DE180055@magilla.sf.frob.com> Message-ID: <200704051659.59432.jkeating@redhat.com> On Thursday 05 April 2007 16:47:12 Roland McGrath wrote: > The final tree picture on the page shows all of: > > ????????core/development > ????????development > ????????extras/development > > are those supposed to be: > > ????????core/development -> ../development > ????????development > ????????extras/development -> ../development > > ? ?Or else, what does it mean? ?We're not going to have both merged and > unmerged copies of all the development/ contents on mirrors are we? For a period of time, the core/development and extras/development content will stick around as it was last updated. This will allow mirrors to have something to hardlink against for the new merged content in linux/development. After a short time, the core/development will become a symlink to linux/development as will extras/development become a symlink to the same place, for a period of time before the directories are expunged all together. -- 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 wtogami at redhat.com Thu Apr 5 20:59:38 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 05 Apr 2007 16:59:38 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704051659.59432.jkeating@redhat.com> References: <20070405204712.766DE180055@magilla.sf.frob.com> <200704051659.59432.jkeating@redhat.com> Message-ID: <4615633A.70204@redhat.com> Jesse Keating wrote: > > For a period of time, the core/development and extras/development content will > stick around as it was last updated. This will allow mirrors to have > something to hardlink against for the new merged content in > linux/development. After a short time, the core/development will become a > symlink to linux/development as will extras/development become a symlink to > the same place, for a period of time before the directories are expunged all > together. > Might it be a better to symlink core/development to linux/development, and make extras/development into an empty repo? That way yum isn't grabbing the same metadata twice. Warren From wtogami at redhat.com Thu Apr 5 21:08:48 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 05 Apr 2007 17:08:48 -0400 Subject: FYI: fedorabugs auto-add Message-ID: <46156560.8040206@redhat.com> Toshio added new code to FAS yesterday that automatically adds people to fedorabugs if they are sponsored in cvsextras. This should help to smooth the process a bit, so people aren't confused as to why they can't set the fedora-cvs flag in Bugzilla. I am now retroactively adding fedorabugs membership to 128 members of cvsextras who don't already have it. Warren Togami wtogami at redhat.com From poelstra at redhat.com Thu Apr 5 21:25:42 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 05 Apr 2007 14:25:42 -0700 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704051659.59432.jkeating@redhat.com> References: <20070405204712.766DE180055@magilla.sf.frob.com> <200704051659.59432.jkeating@redhat.com> Message-ID: <46156956.2000802@redhat.com> Jesse Keating said the following on 04/05/2007 01:59 PM Pacific Time: > On Thursday 05 April 2007 16:47:12 Roland McGrath wrote: >> The final tree picture on the page shows all of: >> >> core/development >> development >> extras/development >> >> are those supposed to be: >> >> core/development -> ../development >> development >> extras/development -> ../development >> >> ? Or else, what does it mean? We're not going to have both merged and >> unmerged copies of all the development/ contents on mirrors are we? > > For a period of time, the core/development and extras/development content will > stick around as it was last updated. This will allow mirrors to have > something to hardlink against for the new merged content in > linux/development. After a short time, the core/development will become a > symlink to linux/development as will extras/development become a symlink to > the same place, for a period of time before the directories are expunged all > together. > Why do we need the parent "linux" directory if it only has one child? Seems to me that getting rid of it would be a nice think like happened to RPMS on the install disks. John From Axel.Thimm at ATrpms.net Thu Apr 5 21:52:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 5 Apr 2007 23:52:02 +0200 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704051640.14557.jkeating@redhat.com> References: <200704051640.14557.jkeating@redhat.com> Message-ID: <20070405215202.GJ16463@neu.nirvana> On Thu, Apr 05, 2007 at 04:40:14PM -0400, Jesse Keating wrote: > I've tossed together a quick rundown of a new mirror layout for the merged > core and extras. You can find it here: > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge#head-d370223ce90e602f6d5c4bf3584bd20800da68b6 > > Any feedback would be appreciated. This could be expected to go live as early > as Monday Apr 9th. Looks nice, thanks! Two comments: o relative symlinks with '../' are doomed to break on mirrors, as content is usually split around volumes as needs arise, so I would suggest to not use any such symlinks. o mirrors should be prepared for that switch, but currently only core and extras subfolders are exported to them via rsync. It would make sense to open up rsync modules (for the mirrors) at the linux hierarchy as soon as possible, so the mirrors can adjust before the layout switch. The nice side effect would be that mirrors could use the same rsync module for mirroring other content, too, like liveos or epel stuff. -- 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 dennis at ausil.us Thu Apr 5 21:56:46 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 5 Apr 2007 16:56:46 -0500 Subject: New mirror layout for the merged core and extras In-Reply-To: <20070405215202.GJ16463@neu.nirvana> References: <200704051640.14557.jkeating@redhat.com> <20070405215202.GJ16463@neu.nirvana> Message-ID: <200704051656.46911.dennis@ausil.us> On Thursday 05 April 2007 04:52:02 pm Axel Thimm wrote: > On Thu, Apr 05, 2007 at 04:40:14PM -0400, Jesse Keating wrote: > > I've tossed together a quick rundown of a new mirror layout for the > > merged core and extras. You can find it here: > > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge#head-d370223 > >ce90e602f6d5c4bf3584bd20800da68b6 > > > > Any feedback would be appreciated. This could be expected to go live as > > early as Monday Apr 9th. > > Looks nice, thanks! > > Two comments: > > o relative symlinks with '../' are doomed to break on mirrors, as > content is usually split around volumes as needs arise, so I would > suggest to not use any such symlinks. > > o mirrors should be prepared for that switch, but currently only core > and extras subfolders are exported to them via rsync. It would make > sense to open up rsync modules (for the mirrors) at the linux > hierarchy as soon as possible, so the mirrors can adjust before the > layout switch. The nice side effect would be that mirrors could use > the same rsync module for mirroring other content, too, like liveos > or epel stuff. epel is a whole different tree. branched off at /pub/ so your proposal wont expose epel -- Dennis Gilmore, RHCE From wtogami at redhat.com Thu Apr 5 21:59:19 2007 From: wtogami at redhat.com (Warren Togami) Date: Thu, 05 Apr 2007 17:59:19 -0400 Subject: Rename cvsextras to packager In-Reply-To: <46153EB8.5010502@redhat.com> References: <46151808.9010606@redhat.com> <1175788860.13917.4.camel@lincoln> <46153EB8.5010502@redhat.com> Message-ID: <46157137.4030502@redhat.com> Warren Togami wrote: > Brian Pepple wrote: >> On Thu, 2007-04-05 at 11:38 -0400, Warren Togami wrote: >>> The name 'cvsextras' is confusing. We should rename it to something >>> like 'packager' which reflects the actual purpose of the group. >>> >>> We should discuss this during today's FESCO meeting. >> >> Agreed. I'll add it to the schedule. >> > > Agreement during the FESCO meeting today is to delay renaming this, in > order to avoid changing too many things at once. > Although that was based upon jeremy's desire to avoid making other changes when the BIG change of CVS/buildsys merge is happening this weekend. If the big merge becomes delayed (still uncertain), then I intend on making the cvsextras -> packager rename happen sooner, in order to reduce confusion in the resulting merged project. Jeremy agreed to this. I will prepare for this in parallel. Thursday through Sunday: identify all places that need cvsextras changed to packagers. Prepare all code and database changes. Monday: If CVS/buildsys merge has not happened by this point, then get buy-in from FESCO and FI, and do it. Warren Togami wtogami at redhat.com From Axel.Thimm at ATrpms.net Thu Apr 5 22:21:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 6 Apr 2007 00:21:40 +0200 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704051656.46911.dennis@ausil.us> References: <200704051640.14557.jkeating@redhat.com> <20070405215202.GJ16463@neu.nirvana> <200704051656.46911.dennis@ausil.us> Message-ID: <20070405222140.GM16463@neu.nirvana> On Thu, Apr 05, 2007 at 04:56:46PM -0500, Dennis Gilmore wrote: > On Thursday 05 April 2007 04:52:02 pm Axel Thimm wrote: > > On Thu, Apr 05, 2007 at 04:40:14PM -0400, Jesse Keating wrote: > > > I've tossed together a quick rundown of a new mirror layout for the > > > merged core and extras. You can find it here: > > > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge#head-d370223 > > >ce90e602f6d5c4bf3584bd20800da68b6 > > > > > > Any feedback would be appreciated. This could be expected to go live as > > > early as Monday Apr 9th. > > > > Looks nice, thanks! > > > > Two comments: > > > > o relative symlinks with '../' are doomed to break on mirrors, as > > content is usually split around volumes as needs arise, so I would > > suggest to not use any such symlinks. > > > > o mirrors should be prepared for that switch, but currently only core > > and extras subfolders are exported to them via rsync. It would make > > sense to open up rsync modules (for the mirrors) at the linux > > hierarchy as soon as possible, so the mirrors can adjust before the > > layout switch. The nice side effect would be that mirrors could use > > the same rsync module for mirroring other content, too, like liveos > > or epel stuff. > > epel is a whole different tree. branched off at /pub/ so your proposal wont > expose epel Then maybe we need an even higher access point for mirrors, or need to pull epel down the hierarchy? It is very likely that mirrors for Fedora will mirror epel, too, so that will make live easier for mirror admins. I know it would make mine easier :) -- 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 notting at redhat.com Fri Apr 6 02:38:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 5 Apr 2007 22:38:11 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704051640.14557.jkeating@redhat.com> References: <200704051640.14557.jkeating@redhat.com> Message-ID: <20070406023811.GA25512@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > I've tossed together a quick rundown of a new mirror layout for the merged > core and extras. You can find it here: > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge#head-d370223ce90e602f6d5c4bf3584bd20800da68b6 > > Any feedback would be appreciated. This could be expected to go live as early > as Monday Apr 9th. I don't see anything delinated as to how isos/spins will be organized. Bill From katzj at redhat.com Fri Apr 6 03:04:02 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 05 Apr 2007 23:04:02 -0400 Subject: CVS/Buildsys Downtime Postponed In-Reply-To: <200704030924.07004.dennis@ausil.us> References: <200704030924.07004.dennis@ausil.us> Message-ID: <1175828642.19748.21.camel@aglarond.local> On Tue, 2007-04-03 at 09:24 -0500, Dennis Gilmore wrote: > This is the final piece to having a merged fedora. Thank you in advance for > your patience and understanding. Unfortunately, due to some issues with the amount of build capacity in the colo facility and some difficulties in expanding our builders in the very short term, we're going to have to put this off for now. We'll work on getting a new plan together and published over the course of the next week. Jeremy From dwmw2 at infradead.org Fri Apr 6 07:05:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 06 Apr 2007 03:05:18 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704051640.14557.jkeating@redhat.com> References: <200704051640.14557.jkeating@redhat.com> Message-ID: <1175843118.2764.27.camel@shinybook.infradead.org> On Thu, 2007-04-05 at 16:40 -0400, Jesse Keating wrote: > Any feedback would be appreciated. This could be expected to go live > as early as Monday Apr 9th. Any chance we could do that kind of change on a Friday night instead? That way, I can abuse my DSL line all weekend while the bandwidth isn't being counted. I already doubled my 'peak hours' allowance for last month when everything from Fedora/RPMS/ moved up a directory and spent all day copying on a Monday -- I'd rather not have it happen again. Obviously I could handle this manually for myself, but I suspect I'm far from the only one mirroring the tree for whom weekend bandwidth is cheaper than weekdays... -- dwmw2 From sundaram at fedoraproject.org Fri Apr 6 07:10:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 06 Apr 2007 12:40:02 +0530 Subject: Plan for tomorrows (20070405) FESCO meeting In-Reply-To: <46147FC1.3050805@leemhuis.info> References: <1175731405.28653.7.camel@lincoln> <46144E26.7080504@fedoraproject.org> <46147FC1.3050805@leemhuis.info> Message-ID: <4615F24A.5020905@fedoraproject.org> Thorsten Leemhuis wrote: > On 05.04.2007 04:45, Jason L Tibbitts III wrote: >>>>>>> "RS" == Rahul Sundaram writes: >> RS> Do consider adding Packaging Conflicts to the topics. >> Also note http://fedoraproject.org/wiki/PackagingDrafts/Conflicts >> Discussion in the last PC meeting in January >> (http://fedoraproject.org/wiki/Packaging/IRCLog20070130) indicates >> that this draft was approved by PC and FESCo. I am not sure why I >> can't seem to find it in the guidelines. > > I asked that two or three times in the past, too, without getting a > reply :-( > > Further: Having a guideline doesn't solve the problem. Someone needs to > enforce it. And that's FESCo's job afaics. We also need to determine the approach to resolve conflicts for existing packages in the repository. Does a small team do it? Do we file bug reports? Rahul From fedora at leemhuis.info Fri Apr 6 09:05:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 11:05:11 +0200 Subject: New mirror layout for the merged core and extras In-Reply-To: <1175843118.2764.27.camel@shinybook.infradead.org> References: <200704051640.14557.jkeating@redhat.com> <1175843118.2764.27.camel@shinybook.infradead.org> Message-ID: <46160D47.8020003@leemhuis.info> David Woodhouse schrieb: > On Thu, 2007-04-05 at 16:40 -0400, Jesse Keating wrote: >> Any feedback would be appreciated. This could be expected to go live >> as early as Monday Apr 9th. > Any chance we could do that kind of change on a Friday night instead? > That way, I can abuse my DSL line all weekend while the bandwidth isn't > being counted. I already doubled my 'peak hours' allowance for last > month when everything from Fedora/RPMS/ moved up a directory and spent > all day copying on a Monday -- I'd rather not have it happen again. > Obviously I could handle this manually for myself, but I suspect I'm far > from the only one mirroring the tree for whom weekend bandwidth is > cheaper than weekdays... Last time Jesse did some major adjustments on the directory layout on the server (one year ago iirc -- can remember what the reasons was) the files were hardlinked into the new place and deleted one or two weeks later in the old place; someone that regularly rsyncs with the proper parameters doesn't have to download everything anew that way iirc. Isn't this a option this time? Or am I missing something? CU thl From bkoz at redhat.com Fri Apr 6 10:08:52 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Fri, 06 Apr 2007 12:08:52 +0200 Subject: Fedora Account System Changes In-Reply-To: <1175739168.30064.38.camel@localhost.localdomain> References: <1175739168.30064.38.camel@localhost.localdomain> Message-ID: <46161C34.6080800@redhat.com> > 1) When you are approved for cvsextras, you are automatically approved > for fedorabugs. This means that once you have the ability to commit to > Fedora CVS you gain the ability to make changes to bug reports in > bugzilla. This is the policy we've had for quite a long time but > formerly it required users to request membership in the second group and > find someone to add them. Note that we haven't yet made a pass through > cvsextras to add everyone there to fedorabugs so if you don't have > fedorabugs but do have commit access to the repository, go ahead and > request membership as you would have in the past. Hmm. What's cvsextras? Is there a cvscore? > 2) Since Red Hat legal has decided that Red Hat employees have the > equivalent of signing the CLA because of the terms of their employment, > we needed to restructure the cla_done group to show whether a person has > passed the CLA barrier by signing the Fedora Individual Contributor > License Agreement (and thus is a member of cla_done until/unless they > revoke it) or by being employed by a company that's signed a corporate > CLA (in which case cla_done would be dropped when the person is no > longer an employee.) We implemented this by creating new groups for > each class of CLA. People who've signed the Fedora CLA are now members > of cla_fedora. Employees of Red Hat are in cla_redhat. Dell employees > (which has a similar corporate CLA to cover employees contributing to > Fedora) are covered by cla_dell. Membership in any of these groups > automatically grants cla_done so existing code that looks at whether > someone is in cla_done will continue to function. I can now add myself to cla_redhat, so thanks. However, I need to add myself to cla_done to add to any groups like cvsextras, etc. I'm a bit confused about the account edit page on fedoraprojects.org. In general, I'm not sure what groups I'm supposed to "add," or why I'm supposed to add them. I don't see a master list of possible groups anywhere, or a way to get a sponsor if I need one. (What's this? Who approves stuff?) What's the master list of groups that a new account owner should have if they were a maintainer of a core package in the old fedora system? Thanks for spelling this out. best, benjamin From jkeating at redhat.com Fri Apr 6 10:56:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 06:56:26 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <20070406023811.GA25512@nostromo.devel.redhat.com> References: <200704051640.14557.jkeating@redhat.com> <20070406023811.GA25512@nostromo.devel.redhat.com> Message-ID: <200704060656.30511.jkeating@redhat.com> On Thursday 05 April 2007 22:38:11 Bill Nottingham wrote: > I don't see anything delinated as to how isos/spins will be organized. I wasn't going to cover that quite yet, but probably follow how things were done for test releases. releases/7/ /Prime/ // /iso /Live/ // /iso /Everything/ // /os/ /debug/ /source/ -- 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 10:57:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 06:57:29 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <46160D47.8020003@leemhuis.info> References: <200704051640.14557.jkeating@redhat.com> <1175843118.2764.27.camel@shinybook.infradead.org> <46160D47.8020003@leemhuis.info> Message-ID: <200704060657.29613.jkeating@redhat.com> On Friday 06 April 2007 05:05:11 Thorsten Leemhuis wrote: > Last time Jesse did some major adjustments on the directory layout on > the server (one year ago iirc -- can remember what the reasons was) the > files were hardlinked into the new place and deleted one or two weeks > later in the old place; someone that regularly rsyncs with the proper > parameters doesn't have to download everything anew that way iirc. Isn't > this a option this time? Or am I missing something? That could be an option this time. Given that we've delayed the merger until we can get more builders in place in the colo, we have more time to prepare the new layout. -- 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 11:02:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 07:02:23 -0400 Subject: Fedora Account System Changes In-Reply-To: <46161C34.6080800@redhat.com> References: <1175739168.30064.38.camel@localhost.localdomain> <46161C34.6080800@redhat.com> Message-ID: <200704060702.23935.jkeating@redhat.com> On Friday 06 April 2007 06:08:52 Benjamin Kosnik wrote: > However, I need to add myself to cla_done to add to any groups like > cvsextras, etc. > > I'm a bit confused about the account edit page on fedoraprojects.org. > > In general, I'm not sure what groups I'm supposed to "add," or why I'm > supposed to add them. I don't see a master list of possible groups > anywhere, or a way to get a sponsor if I need one. (What's this? Who > approves stuff?) Once you've been approved for cla_redhat (somebody has to verify your employment), you'll automatically be added to cla_done. The next thing you need to apply for is cvsextras, which is where the sponsorship comes in. This is usually the point in which your new package to Fedora has passed review and you're preparing to import it. RH employees already maintaining packages have a slightly different process in that you already maintain a package, you just need access to get to it once we've merged. Once you've been sponsored for cvsextras, you'll automatically get fedorabugs which gives you access to setting flags on Fedora bugs (which you may already have given you have a redhat.com account). That should be all the groups you need to function as a Fedora package maintainer. -- 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 11:13:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 13:13:03 +0200 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704060656.30511.jkeating@redhat.com> References: <200704051640.14557.jkeating@redhat.com> <20070406023811.GA25512@nostromo.devel.redhat.com> <200704060656.30511.jkeating@redhat.com> Message-ID: <46162B3F.90902@leemhuis.info> Jesse Keating schrieb: > On Thursday 05 April 2007 22:38:11 Bill Nottingham wrote: >> I don't see anything delinated as to how isos/spins will be organized. > I wasn't going to cover that quite yet, but probably follow how things were > done for test releases. > > releases/7/ > /Prime/ > // > /iso > /Live/ > // > /iso > /Everything/ > // > /os/ > /debug/ > /source/ I dislike a bit that /os/ is below Everything. How about something that's similar to what we have now below "core/{5,6}/" releases/7/ // /iso/ /os/{...} /debug/{...} = i386, ppc, x86_64, source The Prime, Live and Everything isos could live in the iso directory for each arch. CU thl From a.badger at gmail.com Fri Apr 6 11:14:01 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 06 Apr 2007 04:14:01 -0700 Subject: Fedora Account System Changes In-Reply-To: <46161C34.6080800@redhat.com> References: <1175739168.30064.38.camel@localhost.localdomain> <46161C34.6080800@redhat.com> Message-ID: <1175858041.22268.24.camel@localhost.localdomain> On Fri, 2007-04-06 at 12:08 +0200, Benjamin Kosnik wrote: > > 1) When you are approved for cvsextras, you are automatically approved > > for fedorabugs. This means that once you have the ability to commit to > > Fedora CVS you gain the ability to make changes to bug reports in > > bugzilla. This is the policy we've had for quite a long time but > > formerly it required users to request membership in the second group and > > find someone to add them. Note that we haven't yet made a pass through > > cvsextras to add everyone there to fedorabugs so if you don't have > > fedorabugs but do have commit access to the repository, go ahead and > > request membership as you would have in the past. > > Hmm. What's cvsextras? Is there a cvscore? > This is a bit confusing. At the moment cvsextras gives access to the externally available cvs repository. The cvs repository for Core is internal to Red Hat and doesn't have an equivalent "cvscore" group in the Fedora Account System. I believe that warren is planning to rename the cvsextras group to "packagers" or another name which can apply to everyone in the new merged repository world. > > 2) Since Red Hat legal has decided that Red Hat employees have the > > equivalent of signing the CLA because of the terms of their employment, > > we needed to restructure the cla_done group to show whether a person has > > passed the CLA barrier by signing the Fedora Individual Contributor > > License Agreement (and thus is a member of cla_done until/unless they > > revoke it) or by being employed by a company that's signed a corporate > > CLA (in which case cla_done would be dropped when the person is no > > longer an employee.) We implemented this by creating new groups for > > each class of CLA. People who've signed the Fedora CLA are now members > > of cla_fedora. Employees of Red Hat are in cla_redhat. Dell employees > > (which has a similar corporate CLA to cover employees contributing to > > Fedora) are covered by cla_dell. Membership in any of these groups > > automatically grants cla_done so existing code that looks at whether > > someone is in cla_done will continue to function. > > I can now add myself to cla_redhat, so thanks. > > However, I need to add myself to cla_done to add to any groups like > cvsextras, etc. > No one should be added directly to cla_done anymore. cla_done will be automatically added when you are approved for one of the other cla_* groups. For people going through the signing of the Fedora Individual CLA, you are added to both cla_fedora and cla_done when the signed cla is processed by the automated system. For people signing up through cla_redhat, the steps are to 1) Add yourself to cla_redhat. 2) The administrator of cla_redhat approves you 3) This approval automatically adds you to cla_done as well. (Looking at the account system, it looks like your cla_redhat request was approved and you are now a member of both cla_redhat and cla_done). > I'm a bit confused about the account edit page on fedoraprojects.org. > > In general, I'm not sure what groups I'm supposed to "add," or why I'm > supposed to add them. I don't see a master list of possible groups > anywhere, or a way to get a sponsor if I need one. (What's this? Who > approves stuff?) > > What's the master list of groups that a new account owner should have if > they were a maintainer of a core package in the old fedora system? cla_fedora OR cla_redhat OR cla_dell (which grants cla_done) cvsextras (will be renamed shortly) fedorabugs (should be autoadded by joining cvsextras. In the past, Red Hat employees haven't needed to join fedorabugs because they already had equivalent permissions on bugzilla. I don't think that's changing but I could be wrong.) The account system *is* very confusing at the moment. We have two projects going on to try to fix that: 1) Karsten Wade, Warren Togami, and Mairin Duffy are spearheading documentation changes that will better explain what a new account owner needs to do to become involved with a specific group. For a package maintainer, there will be a page which clearly documents what groups you need to sign up for in order to work on your packages. 2) Mike Mcgrath is working on rewriting the UI for the account system to be more intuitive, better organized, and altogether make it easier to navigate the account system and figure out what groups are available and how to become a part of them. -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 jwboyer at jdub.homelinux.org Fri Apr 6 11:11:04 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 06 Apr 2007 06:11:04 -0500 Subject: Plan for tomorrows (20070405) FESCO meeting In-Reply-To: <4615F24A.5020905@fedoraproject.org> References: <1175731405.28653.7.camel@lincoln> <46144E26.7080504@fedoraproject.org> <46147FC1.3050805@leemhuis.info> <4615F24A.5020905@fedoraproject.org> Message-ID: <1175857864.32658.65.camel@vader.jdub.homelinux.org> On Fri, 2007-04-06 at 12:40 +0530, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > On 05.04.2007 04:45, Jason L Tibbitts III wrote: > >>>>>>> "RS" == Rahul Sundaram writes: > >> RS> Do consider adding Packaging Conflicts to the topics. > >> Also note http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > >> Discussion in the last PC meeting in January > >> (http://fedoraproject.org/wiki/Packaging/IRCLog20070130) indicates > >> that this draft was approved by PC and FESCo. I am not sure why I > >> can't seem to find it in the guidelines. > > > > I asked that two or three times in the past, too, without getting a > > reply :-( > > > > Further: Having a guideline doesn't solve the problem. Someone needs to > > enforce it. And that's FESCo's job afaics. > > We also need to determine the approach to resolve conflicts for existing > packages in the repository. Does a small team do it? Do we file bug reports? I would think bug reports should be filed irregardless of who will be doing the fixing. It provides some kind of tracking and launch pad for cleanup. josh From jkeating at redhat.com Fri Apr 6 11:21:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 07:21:29 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <46162B3F.90902@leemhuis.info> References: <200704051640.14557.jkeating@redhat.com> <200704060656.30511.jkeating@redhat.com> <46162B3F.90902@leemhuis.info> Message-ID: <200704060721.29550.jkeating@redhat.com> On Friday 06 April 2007 07:13:03 Thorsten Leemhuis wrote: > I dislike a bit that /os/ is below Everything. How about something > that's similar to what we have now below "core/{5,6}/" > > releases/7/ > ? ? ? ? ? // > ? ? ? ? ? ? ? ? ?/iso/ > ? ? ? ? ? ? ? ? ?/os/{...} > ? ? ? ? ? ? ? ? ?/debug/{...} > > = i386, ppc, x86_64, source > > The Prime, Live and Everything isos could live in the iso directory for > each arch. Why do you dislike that? The idea was that Everything/ has the exploaded content for every arch we build for, regardless if it is pulled into a spin or not. There wouldn't be any exploaded tree for the spins, as that duplicates data and the iso itself can be used in a loopback manner for network installs. Having all the isos in the same directory makes nfsiso installs tricky as anaconda might end up mounting too many isos. -- 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 11:41:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 13:41:30 +0200 Subject: New mirror layout for the merged core and extras In-Reply-To: <200704060721.29550.jkeating@redhat.com> References: <200704051640.14557.jkeating@redhat.com> <200704060656.30511.jkeating@redhat.com> <46162B3F.90902@leemhuis.info> <200704060721.29550.jkeating@redhat.com> Message-ID: <461631EA.7030200@leemhuis.info> Jesse Keating schrieb: > On Friday 06 April 2007 07:13:03 Thorsten Leemhuis wrote: >> I dislike a bit that /os/ is below Everything. How about something >> that's similar to what we have now below "core/{5,6}/" >> >> releases/7/ >> // >> /iso/ >> /os/{...} >> /debug/{...} >> >> = i386, ppc, x86_64, source >> >> The Prime, Live and Everything isos could live in the iso directory for >> each arch. > Why do you dislike that? No specific reasons, just a "looks better to me that way" and "is closer to what we had until now which worked fine up to now -- changing it more then needed just confuses people for no good reasons" feeling. Well, maybe a small detail: you don't have to type the "Everything" part of the url when doing network installs. > The idea was that Everything/ has the exploaded > content for every arch we build for, regardless if it is pulled into a spin > or not. There wouldn't be any exploaded tree for the spins, as that > duplicates data and the iso itself can be used in a loopback manner for > network installs. Well, all that is afaics possible with the layout I outlined, too. (and I didn't want any exploaded spins trees, too -- only the repo with all the packages in it) > Having all the isos in the same directory makes nfsiso > installs tricky as anaconda might end up mounting too many isos. The make subdirectories for each spin below iso and the problem is gone. Cu thl From bkoz at redhat.com Fri Apr 6 12:22:50 2007 From: bkoz at redhat.com (Benjamin Kosnik) Date: Fri, 06 Apr 2007 14:22:50 +0200 Subject: Fedora Account System Changes In-Reply-To: <1175858041.22268.24.camel@localhost.localdomain> References: <1175739168.30064.38.camel@localhost.localdomain> <46161C34.6080800@redhat.com> <1175858041.22268.24.camel@localhost.localdomain> Message-ID: <46163B9A.2050508@redhat.com> Thanks for both replies. > This is a bit confusing. At the moment cvsextras gives access to the > externally available cvs repository. The cvs repository for Core is > internal to Red Hat and doesn't have an equivalent "cvscore" group in > the Fedora Account System. Ahh. > I believe that warren is planning to rename the cvsextras group to > "packagers" or another name which can apply to everyone in the new > merged repository world. This sounds much more sane. > No one should be added directly to cla_done anymore. cla_done will be > automatically added when you are approved for one of the other cla_* > groups. For people going through the signing of the Fedora Individual > CLA, you are added to both cla_fedora and cla_done when the signed cla > is processed by the automated system. For people signing up through > cla_redhat, the steps are to > 1) Add yourself to cla_redhat. > 2) The administrator of cla_redhat approves you > 3) This approval automatically adds you to cla_done as well. > > (Looking at the account system, it looks like your cla_redhat request > was approved and you are now a member of both cla_redhat and cla_done). Thanks for clarifying the workflow. Indeed, it looks like I just had to type in "cla_redhat" in the "Add new membership" box, and the right people did everything else. Great. >> What's the master list of groups that a new account owner should have if >> they were a maintainer of a core package in the old fedora system? > > cla_fedora OR cla_redhat OR cla_dell (which grants cla_done) > > cvsextras (will be renamed shortly) This is necessary documentation for the process and should be on admin.fedoraproject.org/accounts > 1) Karsten Wade, Warren Togami, and Mairin Duffy are spearheading > documentation changes that will better explain what a new account owner > needs to do to become involved with a specific group. For a package > maintainer, there will be a page which clearly documents what groups you > need to sign up for in order to work on your packages. Great. > 2) Mike Mcgrath is working on rewriting the UI for the account system to > be more intuitive, better organized, and altogether make it easier to > navigate the account system and figure out what groups are available and > how to become a part of them. Ok. Thanks for the info! best, benjamin From buildsys at fedoraproject.org Fri Apr 6 12:32:43 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 6 Apr 2007 08:32:43 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-06 Message-ID: <20070406123243.5E48B152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) mr.ecik AT gmail.com: kadu FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) shahms AT shahms.com: bzrtools FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- bzrtools: shahms AT shahms.com FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) kadu: mr.ecik AT gmail.com FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From rdieter at math.unl.edu Fri Apr 6 14:03:13 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 06 Apr 2007 09:03:13 -0500 Subject: cmake draft ratified Message-ID: <46165321.9050101@math.unl.edu> http://fedoraproject.org/wiki/PackagingDrafts/cmake has recently been passed by FPC and ratified by FESCo. I am now working with the cmake maintainer (OrionPoplawski) to incorporate the suggested rpm macros into it's packaging soon. When that is done, I'll move the contents of the draft under /Packaging/... proper. Further feedback is welcome/encouraged. -- Rex From belegdol at gmail.com Fri Apr 6 15:14:26 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 06 Apr 2007 17:14:26 +0200 Subject: cmake draft ratified In-Reply-To: <46165321.9050101@math.unl.edu> References: <46165321.9050101@math.unl.edu> Message-ID: <461663D2.4060003@gmail.gom> Rex Dieter napisa?(a): > http://fedoraproject.org/wiki/PackagingDrafts/cmake > has recently been passed by FPC and ratified by FESCo. > > I am now working with the cmake maintainer (OrionPoplawski) to > incorporate the suggested rpm macros into it's packaging soon. When > that is done, I'll move the contents of the draft under /Packaging/... > proper. > > Further feedback is welcome/encouraged. > > -- Rex > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Nice. I think something similar for scons would be really helpful. From limb at jcomserv.net Fri Apr 6 14:17:15 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 6 Apr 2007 09:17:15 -0500 (CDT) Subject: cmake draft ratified In-Reply-To: <461663D2.4060003@gmail.gom> References: <46165321.9050101@math.unl.edu> <461663D2.4060003@gmail.gom> Message-ID: <45779.65.192.24.190.1175869035.squirrel@mail.jcomserv.net> > > Nice. I think something similar for scons would be really helpful. +1 -- novus ordo absurdum From mattdm at mattdm.org Fri Apr 6 14:57:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 6 Apr 2007 10:57:34 -0400 Subject: "test#" fedora versions in bugzilla Message-ID: <20070406145734.GA31701@jadzia.bu.edu> Other than "to create horrible confusion and long-lasting piles of cruft!", what is the intention with these? Can we kill them? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dwmw2 at infradead.org Fri Apr 6 14:59:55 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 06 Apr 2007 10:59:55 -0400 Subject: New mirror layout for the merged core and extras In-Reply-To: <46160D47.8020003@leemhuis.info> References: <200704051640.14557.jkeating@redhat.com> <1175843118.2764.27.camel@shinybook.infradead.org> <46160D47.8020003@leemhuis.info> Message-ID: <1175871596.2764.50.camel@shinybook.infradead.org> On Fri, 2007-04-06 at 11:05 +0200, Thorsten Leemhuis wrote: > Last time Jesse did some major adjustments on the directory layout on > the server (one year ago iirc -- can remember what the reasons was the > files were hardlinked into the new place and deleted one or two weeks > later in the old place; someone that regularly rsyncs with the proper > parameters doesn't have to download everything anew that way iirc. > Isn't this a option this time? Or am I missing something? That would help -- but only for people who were already mirroring Extras, and who have the 'proper parameters' to rsync. What are those, btw? -- dwmw2 From bpepple at fedoraproject.org Fri Apr 6 15:20:43 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 06 Apr 2007 11:20:43 -0400 Subject: Plan for tomorrows (20070405) FESCO meeting In-Reply-To: <1175857864.32658.65.camel@vader.jdub.homelinux.org> References: <1175731405.28653.7.camel@lincoln> <46144E26.7080504@fedoraproject.org> <46147FC1.3050805@leemhuis.info> <4615F24A.5020905@fedoraproject.org> <1175857864.32658.65.camel@vader.jdub.homelinux.org> Message-ID: <1175872843.5743.6.camel@lincoln> On Fri, 2007-04-06 at 06:11 -0500, Josh Boyer wrote: > On Fri, 2007-04-06 at 12:40 +0530, Rahul Sundaram wrote: > > > > We also need to determine the approach to resolve conflicts for existing > > packages in the repository. Does a small team do it? Do we file bug reports? > > I would think bug reports should be filed irregardless of who will be > doing the fixing. It provides some kind of tracking and launch pad for > cleanup. +1 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 Fri Apr 6 15:24:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Apr 2007 17:24:48 +0200 Subject: New mirror layout for the merged core and extras In-Reply-To: <1175871596.2764.50.camel@shinybook.infradead.org> References: <200704051640.14557.jkeating@redhat.com> <1175843118.2764.27.camel@shinybook.infradead.org> <46160D47.8020003@leemhuis.info> <1175871596.2764.50.camel@shinybook.infradead.org> Message-ID: <46166640.3050501@leemhuis.info> David Woodhouse schrieb: > On Fri, 2007-04-06 at 11:05 +0200, Thorsten Leemhuis wrote: >> Last time Jesse did some major adjustments on the directory layout on >> the server (one year ago iirc -- can remember what the reasons was the >> files were hardlinked into the new place and deleted one or two weeks >> later in the old place; someone that regularly rsyncs with the proper >> parameters doesn't have to download everything anew that way iirc. >> Isn't this a option this time? Or am I missing something? > That would help -- but only for people who were already mirroring > Extras, Well, you at least to download rawhide itself anew. But yes, if you didn't mirror Extras yet, then you now are forces to... /me mirrors rawhide (and not Extras) in two places and fears the merged world a bit due to the new space and bandwidth requirements.... > and who have the 'proper parameters' to rsync. What are those, > btw? /me checks >From the man page: [...] -H, --hard-links preserve hard links [...] -H, --hard-links This tells rsync to look for hard-linked files in the transfer and link together the corresponding files on the receiving side. Without this option, hard-linked files in the transfer are treated as though they were separate files. Note that rsync can only detect hard links if both parts of the link are in the list of files being sent. CU thl From jkeating at redhat.com Fri Apr 6 15:44:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 11:44:15 -0400 Subject: "test#" fedora versions in bugzilla In-Reply-To: <20070406145734.GA31701@jadzia.bu.edu> References: <20070406145734.GA31701@jadzia.bu.edu> Message-ID: <200704061144.19302.jkeating@redhat.com> On Friday 06 April 2007 10:57:34 Matthew Miller wrote: > Other than "to create horrible confusion and long-lasting piles of cruft!", > what is the intention with these? Can we kill them? The plan is to kill them. -- 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 Fri Apr 6 15:49:02 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 6 Apr 2007 11:49:02 -0400 Subject: "test#" fedora versions in bugzilla In-Reply-To: <200704061144.19302.jkeating@redhat.com> References: <20070406145734.GA31701@jadzia.bu.edu> <200704061144.19302.jkeating@redhat.com> Message-ID: <20070406154902.GA3368@jadzia.bu.edu> On Fri, Apr 06, 2007 at 11:44:15AM -0400, Jesse Keating wrote: > > Other than "to create horrible confusion and long-lasting piles of cruft!", > > what is the intention with these? Can we kill them? > The plan is to kill them. Okay. I'm going to add the bugs open against them to my triage hitlist, then. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From orion at cora.nwra.com Fri Apr 6 17:28:22 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 06 Apr 2007 11:28:22 -0600 Subject: cmake draft ratified In-Reply-To: <46165321.9050101@math.unl.edu> References: <46165321.9050101@math.unl.edu> Message-ID: <46168336.1030502@cora.nwra.com> Rex Dieter wrote: > http://fedoraproject.org/wiki/PackagingDrafts/cmake > has recently been passed by FPC and ratified by FESCo. > > I am now working with the cmake maintainer (OrionPoplawski) to > incorporate the suggested rpm macros into it's packaging soon. When > that is done, I'll move the contents of the draft under /Packaging/... > proper. > > Further feedback is welcome/encouraged. cmake-2.6.4-2.fc7 has just been built on development. Let me know how it goes. If there are no problems I'll push for FC5 and FC6. Thanks to Rex for pushing this process forward. -- 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 mszpak at wp.pl Fri Apr 6 18:32:29 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Fri, 06 Apr 2007 20:32:29 +0200 Subject: cmake draft ratified In-Reply-To: <461663D2.4060003@gmail.gom> References: <46165321.9050101@math.unl.edu> <461663D2.4060003@gmail.gom> Message-ID: <4616923D.4050809@wp.pl> On 2007-04-06 17:14:26 +0200, Julian Sikorski wrote: > Rex Dieter napisa?(a): >> http://fedoraproject.org/wiki/PackagingDrafts/cmake >> has recently been passed by FPC and ratified by FESCo. >> >> I am now working with the cmake maintainer (OrionPoplawski) to >> incorporate the suggested rpm macros into it's packaging soon. When >> that is done, I'll move the contents of the draft under /Packaging/... >> proper. >> >> Further feedback is welcome/encouraged. >> (...) > Nice. I think something similar for scons would be really helpful. +1 Regards Marcin From tibbs at math.uh.edu Fri Apr 6 18:40:53 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Apr 2007 13:40:53 -0500 Subject: cmake draft ratified In-Reply-To: <461663D2.4060003@gmail.gom> References: <46165321.9050101@math.unl.edu> <461663D2.4060003@gmail.gom> Message-ID: >>>>> "JS" == Julian Sikorski writes: JS> Nice. I think something similar for scons would be really helpful. You're welcome to submit a draft. - J< From Matt_Domsch at dell.com Fri Apr 6 20:00:52 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 6 Apr 2007 15:00:52 -0500 Subject: New mirror layout for the merged core and extras In-Reply-To: <1175871596.2764.50.camel@shinybook.infradead.org> References: <200704051640.14557.jkeating@redhat.com> <1175843118.2764.27.camel@shinybook.infradead.org> <46160D47.8020003@leemhuis.info> <1175871596.2764.50.camel@shinybook.infradead.org> Message-ID: <20070406200051.GA15192@lists.us.dell.com> On Fri, Apr 06, 2007 at 10:59:55AM -0400, David Woodhouse wrote: > On Fri, 2007-04-06 at 11:05 +0200, Thorsten Leemhuis wrote: > > Last time Jesse did some major adjustments on the directory layout on > > the server (one year ago iirc -- can remember what the reasons was the > > files were hardlinked into the new place and deleted one or two weeks > > later in the old place; someone that regularly rsyncs with the proper > > parameters doesn't have to download everything anew that way iirc. > > Isn't this a option this time? Or am I missing something? > > That would help -- but only for people who were already mirroring > Extras, and who have the 'proper parameters' to rsync. What are those, > btw? http://fedoraproject.org/wiki/Infrastructure/Mirroring rsync -vaH --exclude-from=${EXCLUDES} --numeric-ids --delete --delete-after --delay-updates \ rsync://downloadN.fedora.redhat.com/fedora-linux-core ${LOCAL_DIR} is what I believe is recommended, for appropriate values of EXCLUDES, N, and LOCAL_DIR. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From belegdol at gmail.com Fri Apr 6 21:38:52 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 06 Apr 2007 23:38:52 +0200 Subject: cmake draft ratified In-Reply-To: References: <46165321.9050101@math.unl.edu> <461663D2.4060003@gmail.gom> Message-ID: <4616BDEC.609@gmail.gom> Jason L Tibbitts III napisa?(a): >>>>>> "JS" == Julian Sikorski writes: > > JS> Nice. I think something similar for scons would be really helpful. > > You're welcome to submit a draft. > > - J< > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Well, the problem is that I don't know what the best practices for using it are, nor am that familiar with macros. Maybe some power user will share his knowledge. From buildsys at fedoraproject.org Sat Apr 7 10:07:37 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 7 Apr 2007 06:07:37 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-07 Message-ID: <20070407100737.B7638152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) mr.ecik AT gmail.com: kadu FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) shahms AT shahms.com: bzrtools FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) trond.danielsen AT gmail.com: sdcc FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) ---------------------------------------------------------------------- bzrtools: shahms AT shahms.com FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) kadu: mr.ecik AT gmail.com FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) sdcc: trond.danielsen AT gmail.com FE6 > FE7 (0:2.6.0-9.fc6 > 0:2.6.0-8.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From Fedora at FamilleCollet.com Sat Apr 7 13:15:00 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 07 Apr 2007 15:15:00 +0200 Subject: yum-3.0.5 bug - [Was : Mock builds borked for libgl} In-Reply-To: <46155221.5030905@FamilleCollet.com> References: <46155221.5030905@FamilleCollet.com> Message-ID: <46179954.1060403@FamilleCollet.com> Remi Collet a ?crit : > Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from core. Revert back to yum-3.0.3 solves the issue. Remi. From skvidal at linux.duke.edu Sat Apr 7 15:55:32 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 07 Apr 2007 11:55:32 -0400 Subject: yum-3.0.5 bug - [Was : Mock builds borked for libgl} In-Reply-To: <46179954.1060403@FamilleCollet.com> References: <46155221.5030905@FamilleCollet.com> <46179954.1060403@FamilleCollet.com> Message-ID: <1175961332.19199.98.camel@cutter> On Sat, 2007-04-07 at 15:15 +0200, Remi Collet wrote: > Remi Collet a ?crit : > > Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from core. > > Revert back to yum-3.0.3 solves the issue. > Take a look in updates-testing at yum-3.0.5-2.fc6 - I think it solves this one. thanks, -sv From Fedora at FamilleCollet.com Sun Apr 8 08:42:40 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sun, 08 Apr 2007 10:42:40 +0200 Subject: [solved] yum-3.0.5 bug - [Was : Mock builds borked for libgl} In-Reply-To: <1175961332.19199.98.camel@cutter> References: <46155221.5030905@FamilleCollet.com> <46179954.1060403@FamilleCollet.com> <1175961332.19199.98.camel@cutter> Message-ID: <4618AB00.5020704@FamilleCollet.com> seth vidal a ?crit : > On Sat, 2007-04-07 at 15:15 +0200, Remi Collet wrote: >> Remi Collet a ?crit : >>> Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from core. >> Revert back to yum-3.0.3 solves the issue. >> > > Take a look in updates-testing at yum-3.0.5-2.fc6 - I think it solves > this one. > Solved with yum-3.0.5-2 + yum-install-by-dep-fix.patch See : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235572 Thanks Seth. Remi. From buildsys at fedoraproject.org Sun Apr 8 11:56:59 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 8 Apr 2007 07:56:59 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-08 Message-ID: <20070408115659.1291B152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) mr.ecik AT gmail.com: kadu FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) shahms AT shahms.com: bzrtools FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- bzrtools: shahms AT shahms.com FE6 > FE7 (0:0.15.4-2.fc6 > 0:0.15.4-1.fc7) etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) kadu: mr.ecik AT gmail.com FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From sundaram at fedoraproject.org Sun Apr 8 12:31:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Apr 2007 18:01:07 +0530 Subject: Packages with "fc6" name in Fedora 7 Message-ID: <4618E08B.9020300@fedoraproject.org> Hi The current thinking seems to be to just ignore them* but this is guaranteed to result in a lot of confusion. When end users do a distribution upgrade via yum or Anaconda, some of the packages might not have been updated to the Fedora 7 version due to incorrect packaging or other issues while the rest are packages which are deliberated not rebuild to avoid churn. Debugging a end user system with such a mix of packages is very painful. I would suggest that we consider rebuilding just to avoid the confusion. I consider that a good enough "technical reason". The advantage of less churn in packages is lost quickly since packages receive updates fairly quickly in general. Rahul * https://www.redhat.com/archives/fedora-packaging/2007-April/msg00032.html From fedora at leemhuis.info Sun Apr 8 12:53:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Apr 2007 14:53:24 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <4618E08B.9020300@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> Message-ID: <4618E5C4.9000200@leemhuis.info> Hi! Rahul Sundaram schrieb: > > The current thinking seems to be to just ignore them* but this is > guaranteed to result in a lot of confusion. When end users do a > distribution upgrade via yum or Anaconda, some of the packages might not > have been updated to the Fedora 7 version due to incorrect packaging or > other issues while the rest are packages which are deliberated not > rebuild to avoid churn. Debugging a end user system with such a mix of > packages is very painful. > > I would suggest that we consider rebuilding just to avoid the confusion. > I consider that a good enough "technical reason". The advantage of less > churn in packages is lost quickly since packages receive updates fairly > quickly in general. My take: I'm not sure if that's really worth the trouble and we are quite late in the game for Fedora 7. So maybe we should just ignore this for Fedora 7 and find a better solution for F8 and later. Further: I agree with the direction of your statement regarding the confusion. We IMHO should try to solve this with a guideline like "if you use the disttag then you have to make sure the package gets rebuild once during a devel cycle so the disttag of the resulting packages matches the actual release" together with some docs in the wiki that help people to decide when to use dist and when not to, and how to do manually do what "simply works" when using dist (e.g. make sure upgrade path is proper). I'm willing to help writing those docs if we get a guidline like the one roughly outlines above. Ohh, and reviewers must be educated about this as well, as a lot of them are suggesting new packagers to use disttag everywhere. CU thl From jwboyer at jdub.homelinux.org Sun Apr 8 13:39:24 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 08 Apr 2007 08:39:24 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <4618E08B.9020300@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> Message-ID: <1176039564.32658.70.camel@vader.jdub.homelinux.org> On Sun, 2007-04-08 at 18:01 +0530, Rahul Sundaram wrote: > Hi > > The current thinking seems to be to just ignore them* but this is > guaranteed to result in a lot of confusion. When end users do a > distribution upgrade via yum or Anaconda, some of the packages might not > have been updated to the Fedora 7 version due to incorrect packaging or > other issues while the rest are packages which are deliberated not > rebuild to avoid churn. Debugging a end user system with such a mix of > packages is very painful. > > I would suggest that we consider rebuilding just to avoid the confusion. > I consider that a good enough "technical reason". The advantage of less > churn in packages is lost quickly since packages receive updates fairly > quickly in general. If packages receive updates fairly quickly, then why are there still packages in devel that have .fc6 as the disttag in the repo? I find your assertion to have empirical evidence to the contrary. josh From sundaram at fedoraproject.org Sun Apr 8 13:52:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Apr 2007 19:22:52 +0530 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <1176039564.32658.70.camel@vader.jdub.homelinux.org> References: <4618E08B.9020300@fedoraproject.org> <1176039564.32658.70.camel@vader.jdub.homelinux.org> Message-ID: <4618F3B4.5090404@fedoraproject.org> Josh Boyer wrote: > On Sun, 2007-04-08 at 18:01 +0530, Rahul Sundaram wrote: >> Hi >> >> The current thinking seems to be to just ignore them* but this is >> guaranteed to result in a lot of confusion. When end users do a >> distribution upgrade via yum or Anaconda, some of the packages might not >> have been updated to the Fedora 7 version due to incorrect packaging or >> other issues while the rest are packages which are deliberated not >> rebuild to avoid churn. Debugging a end user system with such a mix of >> packages is very painful. >> >> I would suggest that we consider rebuilding just to avoid the confusion. >> I consider that a good enough "technical reason". The advantage of less >> churn in packages is lost quickly since packages receive updates fairly >> quickly in general. > > If packages receive updates fairly quickly, then why are there still > packages in devel that have .fc6 as the disttag in the repo? I find > your assertion to have empirical evidence to the contrary. Note that I said that packages in Fedora gets updates in general quickly. Not that all packages get updates. If every package got updates then we wouldn't need to have a discussion at all about this. So let's not side track and see if we can have some consensus on the approach that we need to take on packages with fc6 in their names. Rahul From jwboyer at jdub.homelinux.org Sun Apr 8 14:27:11 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 08 Apr 2007 09:27:11 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <4618F3B4.5090404@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> <1176039564.32658.70.camel@vader.jdub.homelinux.org> <4618F3B4.5090404@fedoraproject.org> Message-ID: <1176042431.32658.73.camel@vader.jdub.homelinux.org> On Sun, 2007-04-08 at 19:22 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Sun, 2007-04-08 at 18:01 +0530, Rahul Sundaram wrote: > >> Hi > >> > >> The current thinking seems to be to just ignore them* but this is > >> guaranteed to result in a lot of confusion. When end users do a > >> distribution upgrade via yum or Anaconda, some of the packages might not > >> have been updated to the Fedora 7 version due to incorrect packaging or > >> other issues while the rest are packages which are deliberated not > >> rebuild to avoid churn. Debugging a end user system with such a mix of > >> packages is very painful. > >> > >> I would suggest that we consider rebuilding just to avoid the confusion. > >> I consider that a good enough "technical reason". The advantage of less > >> churn in packages is lost quickly since packages receive updates fairly > >> quickly in general. > > > > If packages receive updates fairly quickly, then why are there still > > packages in devel that have .fc6 as the disttag in the repo? I find > > your assertion to have empirical evidence to the contrary. > > Note that I said that packages in Fedora gets updates in general > quickly. Not that all packages get updates. If every package got updates > then we wouldn't need to have a discussion at all about this. So let's > not side track and see if we can have some consensus on the approach > that we need to take on packages with fc6 in their names. Ok fine. So you have roughly 1294 packages in the Extras devel repo that carry the .fc6 disttag, and 54 in rawhide. You're proposing that all of these be rebuilt? How would you forsee this happening? Each maintainer rebuilds their package, or a small group does all of them, or? josh From sundaram at fedoraproject.org Sun Apr 8 14:49:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Apr 2007 20:19:21 +0530 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <1176042431.32658.73.camel@vader.jdub.homelinux.org> References: <4618E08B.9020300@fedoraproject.org> <1176039564.32658.70.camel@vader.jdub.homelinux.org> <4618F3B4.5090404@fedoraproject.org> <1176042431.32658.73.camel@vader.jdub.homelinux.org> Message-ID: <461900F1.6020806@fedoraproject.org> Josh Boyer wrote: > > So you have roughly 1294 packages in the Extras devel repo that carry > the .fc6 disttag, and 54 in rawhide. You're proposing that all of these > be rebuilt? Yes. Afaik, we have rebuilt every package on previous releases for other reasons. There isn't a history of releases with packages having older versions. The advantages just don't seem worth the potential for confusion and pain debugging problems. > How would you forsee this happening? Each maintainer rebuilds their > package, or a small group does all of them, or? I would like to avoid this process stretching out for a long time. Rebuilding can cause issues due to changes elsewhere. So let's do it as early as we can. This is what I would suggest: * Send a announcement here, fedora-devel list asap that we are rebuilding every packages along with an explanation why. * Give the package maintainers a week to do it themselves or agree to let a very small team (2 or 3 members) do it for them. Release engineering team seems appropriate for the task. * Rebuilt all the packages that have not been done by the maintainers after a week. Rahul From jwboyer at jdub.homelinux.org Sun Apr 8 15:02:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 08 Apr 2007 10:02:03 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <461900F1.6020806@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> <1176039564.32658.70.camel@vader.jdub.homelinux.org> <4618F3B4.5090404@fedoraproject.org> <1176042431.32658.73.camel@vader.jdub.homelinux.org> <461900F1.6020806@fedoraproject.org> Message-ID: <1176044523.32658.95.camel@vader.jdub.homelinux.org> On Sun, 2007-04-08 at 20:19 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > > > > So you have roughly 1294 packages in the Extras devel repo that carry > > the .fc6 disttag, and 54 in rawhide. You're proposing that all of these > > be rebuilt? > > Yes. Afaik, we have rebuilt every package on previous releases for > other reasons. There isn't a history of releases with packages having > older versions. The advantages just don't seem worth the potential for > confusion and pain debugging problems. > > > How would you forsee this happening? Each maintainer rebuilds their > > package, or a small group does all of them, or? > > I would like to avoid this process stretching out for a long time. > Rebuilding can cause issues due to changes elsewhere. So let's do it as > early as we can. This is what I would suggest: > > * Send a announcement here, fedora-devel list asap that we are > rebuilding every packages along with an explanation why. > > * Give the package maintainers a week to do it themselves or agree to > let a very small team (2 or 3 members) do it for them. Release > engineering team seems appropriate for the task. > > * Rebuilt all the packages that have not been done by the maintainers > after a week. I'm still skeptical as to the reasons to do this, however your proposal seems sane. This needs to be run by FESCo. Let's get it added to the agenda for the meeting this week. Also, if this is to be done, the timing is somewhat critical. As you may have seen, the buildsys merge was delayed this weekend due to limited builder capacity. So if 1384 packages need to be rebuilt for nothing more than a disttag change, it needs to either be done before the merge while the core builders are still active, or not until the build capacity issue is solved. josh From opensource at till.name Sun Apr 8 17:31:41 2007 From: opensource at till.name (Till Maas) Date: Sun, 08 Apr 2007 19:31:41 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <4618E5C4.9000200@leemhuis.info> References: <4618E08B.9020300@fedoraproject.org> <4618E5C4.9000200@leemhuis.info> Message-ID: <200704081932.03202.opensource@till.name> On So April 8 2007, Thorsten Leemhuis wrote: > My take: I'm not sure if that's really worth the trouble and we are > quite late in the game for Fedora 7. So maybe we should just ignore this > for Fedora 7 and find a better solution for F8 and later. We can do it for FC8 without at as much traffic as now, given yum-presto is then widely used. Also I doubt, that there will be much confusion, as there are already packages without a disttag and I do not see much confusion about it. Also the fedora-release-notes packages mentions Fedora 5.92 in its summary and description and nobody seems to be confused. 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 mattdm at mattdm.org Sun Apr 8 17:46:35 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 8 Apr 2007 13:46:35 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <461900F1.6020806@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> <1176039564.32658.70.camel@vader.jdub.homelinux.org> <4618F3B4.5090404@fedoraproject.org> <1176042431.32658.73.camel@vader.jdub.homelinux.org> <461900F1.6020806@fedoraproject.org> Message-ID: <20070408174635.GA20424@jadzia.bu.edu> On Sun, Apr 08, 2007 at 08:19:21PM +0530, Rahul Sundaram wrote: > early as we can. This is what I would suggest: > * Send a announcement here, fedora-devel list asap that we are > rebuilding every packages along with an explanation why. > * Give the package maintainers a week to do it themselves or agree to > let a very small team (2 or 3 members) do it for them. Release > engineering team seems appropriate for the task. > * Rebuilt all the packages that have not been done by the maintainers > after a week. +1, assuming you mean "every package still tagged fc6". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Sun Apr 8 17:49:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Apr 2007 19:49:11 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <200704081932.03202.opensource@till.name> References: <4618E08B.9020300@fedoraproject.org> <4618E5C4.9000200@leemhuis.info> <200704081932.03202.opensource@till.name> Message-ID: <46192B17.5010001@leemhuis.info> Till Maas schrieb: > On So April 8 2007, Thorsten Leemhuis wrote: > >> My take: I'm not sure if that's really worth the trouble and we are >> quite late in the game for Fedora 7. So maybe we should just ignore this >> for Fedora 7 and find a better solution for F8 and later. > We can do it for FC8 without at as much traffic as now, given yum-presto is > then widely used. My biggest concern ATM (e.g. for doing it for F7) is not the traffic, it's the timing, as doing the rebuild of all those packages before F7-test4 happens will be hard. The best thing for such a rebuild (and remove dists in packages where it's not a big help) would be to do it when a mass-rebuild happens in any case. Not sure if we'll have one for F8, as that's still far away. > Also I doubt, that there will be much confusion, as there > are already packages without a disttag and I do not see much confusion about > it. Also the fedora-release-notes packages mentions Fedora 5.92 in its > summary and description and nobody seems to be confused. I suspect beta testers don't care about such details, but end users might. But yeah, if we chose to not care about packages with "fc6" in the name of F7 or F8 repos, well, then we don't need to do anything and continue as in the past. That FESCo decision afaics. CU thl From opensource at till.name Sun Apr 8 18:06:24 2007 From: opensource at till.name (Till Maas) Date: Sun, 08 Apr 2007 20:06:24 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070408174635.GA20424@jadzia.bu.edu> References: <4618E08B.9020300@fedoraproject.org> <461900F1.6020806@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> Message-ID: <200704082006.31849.opensource@till.name> On So April 8 2007, Matthew Miller wrote: > On Sun, Apr 08, 2007 at 08:19:21PM +0530, Rahul Sundaram wrote: > > early as we can. This is what I would suggest: > > * Send a announcement here, fedora-devel list asap that we are > > rebuilding every packages along with an explanation why. > > * Give the package maintainers a week to do it themselves or agree to > > let a very small team (2 or 3 members) do it for them. Release > > engineering team seems appropriate for the task. > > * Rebuilt all the packages that have not been done by the maintainers > > after a week. > > +1, assuming you mean "every package still tagged fc6". In this case, it can be done completely automatically because the release does not need to be incremented and then no changelog entry is needed. 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 jwboyer at jdub.homelinux.org Sun Apr 8 19:23:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 08 Apr 2007 14:23:00 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <46192B17.5010001@leemhuis.info> References: <4618E08B.9020300@fedoraproject.org> <4618E5C4.9000200@leemhuis.info> <200704081932.03202.opensource@till.name> <46192B17.5010001@leemhuis.info> Message-ID: <1176060181.3492.1.camel@vader.jdub.homelinux.org> On Sun, 2007-04-08 at 19:49 +0200, Thorsten Leemhuis wrote: > Till Maas schrieb: > > On So April 8 2007, Thorsten Leemhuis wrote: > > > >> My take: I'm not sure if that's really worth the trouble and we are > >> quite late in the game for Fedora 7. So maybe we should just ignore this > >> for Fedora 7 and find a better solution for F8 and later. > > We can do it for FC8 without at as much traffic as now, given yum-presto is > > then widely used. > > My biggest concern ATM (e.g. for doing it for F7) is not the traffic, > it's the timing, as doing the rebuild of all those packages before > F7-test4 happens will be hard. It should be noted that there is nothing preventing packagers from doing rebuilds for this right now. If the maintainers of packages still tagged with .fc6 want to rebuild to pick up the .fc7 disttag, they certainly can. josh From jkeating at redhat.com Mon Apr 9 01:16:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 8 Apr 2007 21:16:19 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <200704082006.31849.opensource@till.name> References: <4618E08B.9020300@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> <200704082006.31849.opensource@till.name> Message-ID: <200704082116.24174.jkeating@redhat.com> On Sunday 08 April 2007 14:06:24 Till Maas wrote: > In this case, it can be done completely automatically because the release > does not need to be incremented and then no changelog entry is needed. Rebuild without a changelog entry is something I'm very much against, especially if an issue creeps into the build precisely because it hasn't been rebuilt in a while. Doing this type of rebuild at this point is a no-go IMHO. We're trying to accomplish too many other things with this release. I definitely would never want to see such a rebuild after the last test release, preferably I'd see it before the feature freeze since such rebuilds could pick up new "features". I'm still very much of the opinion that mass builds should only be done when there is a technical reason, flipping a dist tag is not reason enough for me. The only "confusion" comes from us not messaging how Fedora is put together clearly enough, highlighting inheritance from previous releases. We have Matt's rebuilds that happen regularly, these can be reviewed for things we might want to do a real rebuild for, instead of just blindly rebuilding everything for often no good reason. -- 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 Mon Apr 9 02:22:16 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 8 Apr 2007 22:22:16 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <200704082116.24174.jkeating@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> <200704082006.31849.opensource@till.name> <200704082116.24174.jkeating@redhat.com> Message-ID: <20070409022216.GA20485@jadzia.bu.edu> On Sun, Apr 08, 2007 at 09:16:19PM -0400, Jesse Keating wrote: > Doing this type of rebuild at this point is a no-go IMHO. We're trying to > accomplish too many other things with this release. I definitely would never > want to see such a rebuild after the last test release, preferably I'd see it > before the feature freeze since such rebuilds could pick up new "features". That's a serious problem if the package then needs to be rebuilt for a security issue and the new features creep in at that point. Speaking from experience as someone who rebuilds a lot of packages, this is exactly the reason to rebuild all packages at some point in the development cycle. It sucks to discover that a package doesn't actually rebuild cleanly anymore when you really need to do it urgently. Having the dist tag all match is a nice side benefit. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Matt_Domsch at dell.com Mon Apr 9 02:44:10 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 8 Apr 2007 21:44:10 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070409022216.GA20485@jadzia.bu.edu> References: <4618E08B.9020300@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> <200704082006.31849.opensource@till.name> <200704082116.24174.jkeating@redhat.com> <20070409022216.GA20485@jadzia.bu.edu> Message-ID: <20070409024410.GA2998@lists.us.dell.com> On Sun, Apr 08, 2007 at 10:22:16PM -0400, Matthew Miller wrote: > On Sun, Apr 08, 2007 at 09:16:19PM -0400, Jesse Keating wrote: > > Doing this type of rebuild at this point is a no-go IMHO. We're trying to > > accomplish too many other things with this release. I definitely would never > > want to see such a rebuild after the last test release, preferably I'd see it > > before the feature freeze since such rebuilds could pick up new "features". > > That's a serious problem if the package then needs to be rebuilt for a > security issue and the new features creep in at that point. Speaking from > experience as someone who rebuilds a lot of packages, this is exactly the > reason to rebuild all packages at some point in the development cycle. It > sucks to discover that a package doesn't actually rebuild cleanly anymore > when you really need to do it urgently. Having the dist tag all match is a > nice side benefit. I've been doing the rebuilds. Well, incremental rebuilds lately; I haven't purged the whole tree and started from scratch. That takes about 4 days on 4 fast servers last time I tried. Sounds like we're due... Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Extras Rawhide-in-Mock Build Results for x86_64 Mon Apr 2 05:00:32 CDT 2007 Total packages: 2876 Number failed to build: 54 Number expected to fail due to ExclusiveArch or ExcludeArch: 20 Leaving: 34 (there may be some duplicates if rawhide has 2 versions of a package) Extras Rawhide-in-Mock Build Results for i386 Mon Apr 2 05:07:01 CDT 2007 Total packages: 2876 Number failed to build: 29 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 27 (there may be some duplicates if rawhide has 2 versions of a package) Core Rawhide-in-Mock Build Results for i386 Mon Apr 2 04:51:56 CDT 2007 Total packages: 1154 Number failed to build: 36 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 27 (there may be some duplicates if rawhide has 2 versions of a package) Core Rawhide-in-Mock Build Results for x86_64 Mon Apr 2 04:49:18 CDT 2007 Total packages: 1153 Number failed to build: 47 Number expected to fail due to ExclusiveArch or ExcludeArch: 15 Leaving: 32 (there may be some duplicates if rawhide has 2 versions of a package) So, out of 4030 SRPMS total, 66 fail for one reason or another (some ExclusiveArch-dependent failures in that list), or ~1.6%, aren't building properly. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Matt_Domsch at dell.com Mon Apr 9 13:05:46 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 9 Apr 2007 08:05:46 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <200704091222.13532.arnd@arndb.de> References: <4618E08B.9020300@fedoraproject.org> <20070409022216.GA20485@jadzia.bu.edu> <20070409024410.GA2998@lists.us.dell.com> <200704091222.13532.arnd@arndb.de> Message-ID: <20070409130546.GA31504@humbolt.us.dell.com> On Mon, Apr 09, 2007 at 12:22:13PM +0200, Arnd Bergmann wrote: > On Monday 09 April 2007, Matt Domsch wrote: > > So, out of 4030 SRPMS total, 66 fail for one reason or another (some > > ExclusiveArch-dependent failures in that list), or ~1.6%, aren't > > building properly. > > Is there a way to file automated bug reports against these? Not really; we did this all manually in the FC5 timeframe for the failed-to-build-with-mock bugs. Just need a generic blocker bug, then individual package bugs that block the blocker bug, then my tool prints out a nice report of what's known to be bad, and what's bad but has no bug filed. > Regarding the packages that built successfully, can you check if > they at least look reasonably similar to the fc6 binary? > We should probably also look into rebuilding packages which > - do not have the same set of files or file permissions > - have different dependencies > - contain files that changed in size more than a given > percentage (e.g. 10%) during recompiling My tool runs rpmlint and rpmdiff against all packages as they're built and leaves the resulting logfiles in the result/ directory of the package. I don't have anything that will parse them for anything though. I'd be happy to run such a parser if it existed (hint hint). Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From bpepple at fedoraproject.org Mon Apr 9 17:47:30 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 09 Apr 2007 13:47:30 -0400 Subject: FESCo Meeting Summary for 2007-04-05 Message-ID: <1176140850.11098.42.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (c4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Warren Togami (warren) * Josh Boyer (jwb) * Jeremy Katz (jeremy) * Jesse Keating (f13) === Absent === * Tom Callaway (spot) * Bill Nottingham (notting) == Summary == === Packaging Committee Report === * Packaging Committee didn't have any guidelines that needed FESCo approval this week. === cvs-import changes === * Jens Petersen's patch has been applied, and c4chris will send a message to the mailing list informing them of the change. === Package Database === * abadger1999 is looking for help in writing some small scripts, mainly adaptations of things currently using owners.list. If you interested, please contact Toshio. === Package Conflicts === * bpepple will contact Michael Schwendt to see if he has a tool to help identify packages with conflicts, and if he is also interested in helping to fix them. === F7 Preparation === * It was discussed what deadlines we should have for EVR and broken deps. It was suggested that they should be fixed a week before F7t4, otherwise they would be removed. nirik will send a message to the mailing-lists informing the maintainers of this. * Discusses the problem with Zope/plone since it is unable to work w/ Python-2.5. It was decided that pull Zope/plone for F7, rather than push a compat python package. For details on the lengthy discussion of this, please refer to the IRC log. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070405 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 caillon at redhat.com Mon Apr 9 17:57:24 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 09 Apr 2007 13:57:24 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070409022216.GA20485@jadzia.bu.edu> References: <4618E08B.9020300@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> <200704082006.31849.opensource@till.name> <200704082116.24174.jkeating@redhat.com> <20070409022216.GA20485@jadzia.bu.edu> Message-ID: <461A7E84.6030801@redhat.com> Matthew Miller wrote: > Speaking from > experience as someone who rebuilds a lot of packages, this is exactly the > reason to rebuild all packages at some point in the development cycle. It > sucks to discover that a package doesn't actually rebuild cleanly anymore > when you really need to do it urgently. It does suck. Firefox security updates in Fedora have been delayed due to compiler and other toolchain issues, due to GTK+ changes, due to pango changes, etc. Still, That does not warrant a rebuild at this point because new features can crop up and we lose testing on a stable set of packages. I'd rather see a tinderbox-like build happen for these things to catch them. Rebuilds should happen as quickly as we can churn them out, but these builds should be _throwaway_ builds. They should not be released. The main purpose should be to catch things that no longer rebuild properly. This will solve the issue without needlessly pushing new packages to people over a cosmetic change this late in the game. From ville.skytta at iki.fi Mon Apr 9 19:10:09 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 9 Apr 2007 22:10:09 +0300 Subject: check-buildroot and check-rpaths to redhat-rpm-config? Message-ID: <200704092210.09991.ville.skytta@iki.fi> Hello, Now that there's activity on the buildsys-macros/redhat-rpm-config front, would it be possible to move the following scripts from rpmdevtools to one of those packages? /usr/lib/rpm/check-buildroot /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-rpaths-worker The reason for this is that I'd like to add some new utilities to rpmdevtools which come with some new dependencies, and I don't think it's good to have the base buildsys package set grow because of those. And those check-* scripts fit better in redhat-rpm-config IMO. Another approach could be to split those scripts in a rpmdevtools subpackage, or move them to a buildsys-* package that is shipped in the normal repos. Moving them away from rpmdevtools and rpmdevtools away from the base package set would also allow purging a few things that get pulled in just because of some rpmdevtools dependencies that aren't really relevant in build roots. Opinions? From wtogami at redhat.com Mon Apr 9 19:50:16 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 09 Apr 2007 15:50:16 -0400 Subject: Rename cvsextras to packager Message-ID: <461A98F8.9000401@redhat.com> https://www.redhat.com/archives/fedora-infrastructure-list/2007-April/msg00068.html What needs to be changed is straight forward. Now that the CVS/Buildsystem merge is delayed, meanwhile we can safely go ahead with this change to reduce confusion moving forward. This will require taking down CVS for a few minutes in order to propagate the changed group name everywhere. When would we prefer to do this? How about late Thursday after FESCO approves this plan? Warren Togami wtogami at redhat.com From dcantrell at redhat.com Mon Apr 9 21:24:06 2007 From: dcantrell at redhat.com (David Cantrell) Date: Mon, 09 Apr 2007 17:24:06 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <461A7E84.6030801@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> <200704082006.31849.opensource@till.name> <200704082116.24174.jkeating@redhat.com> <20070409022216.GA20485@jadzia.bu.edu> <461A7E84.6030801@redhat.com> Message-ID: <1176153846.26544.36.camel@mortise.boston.redhat.com> On Mon, 2007-04-09 at 13:57 -0400, Christopher Aillon wrote: > Matthew Miller wrote: > > Speaking from > > experience as someone who rebuilds a lot of packages, this is exactly the > > reason to rebuild all packages at some point in the development cycle. It > > sucks to discover that a package doesn't actually rebuild cleanly anymore > > when you really need to do it urgently. > > It does suck. Firefox security updates in Fedora have been delayed due > to compiler and other toolchain issues, due to GTK+ changes, due to > pango changes, etc. > > Still, That does not warrant a rebuild at this point because new > features can crop up and we lose testing on a stable set of packages. > > I'd rather see a tinderbox-like build happen for these things to catch > them. Rebuilds should happen as quickly as we can churn them out, but > these builds should be _throwaway_ builds. They should not be released. > The main purpose should be to catch things that no longer rebuild > properly. This will solve the issue without needlessly pushing new > packages to people over a cosmetic change this late in the game. I do this for the stuff I maintain using scratch builds in brew. This could easily be expanded to an X-line script that just always runs and walks the CVS tree building whatever is the latest tag for devel for a package. It might also be useful to have this kind of system be opt-in for package maintainers rather than dumping everything in at once. Going even further, we could also opt-in spare boxes we have as builders for this system. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Mon Apr 9 22:04:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Apr 2007 17:04:49 -0500 Subject: [GuidelinesChange] Binary Firmware addition Message-ID: <1176156289.3970.57.camel@localhost.localdomain> The following additional text was added to the Packaging/Guidelines Binary Firmware section: The License tag for any firmware that disallows modification should be set to: "Redistributable, no modification permitted" Firmware packages should be named -firmware, where is the driver or other hardware component that the firmware is for. This change was approved by the Fedora Packaging Committee and ratified by FESCO. ~spot From tcallawa at redhat.com Mon Apr 9 22:05:02 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Apr 2007 17:05:02 -0500 Subject: [GuidelinesChange] Post Release Naming Message-ID: <1176156302.3970.58.camel@localhost.localdomain> An additional section was added to the Packaging/NamingGuidelines Package Release section: The old text described post releases as: Post-release packages: Packages released after a "final" version. This usually is due to a quick bugfix release, such as openssl-0.9.6b or gkrellm-2.1.7a. In this case, the non-numeric characters are permitted in the Version: field. The text has now been amended to: Post-release packages: Packages released after a "final" version. These packages contain the same numeric version as the "final" version, but have an additional non-numeric identifier. Details can be found here: Non-Numeric Version in Release Also, a new section under Non-Numeric Version in Release has been added for Post Release Naming: Post-Release packages Like pre-release packages, non-numeric versioned "post-release" packages can be problematic and also must be treated with care. These fall under two generic categories: * Properly ordered simple versions. These are usually due to quick bugfix releases, such as openssl-0.9.6b or gkrellm-2.1.7a. As new versions come out, the non-numeric tag is properly incremented (e.g. openssl-0.9.6c) or the numeric version is increased and the non-numeric tag is dropped (openssl-0.9.7). In this case, the non-numeric characters are permitted in the Version: field. * When upstream uses versions that attempt to have meaning to humans instead of being easy for a computer to order. For example, GA1, CR2, PR3. In this case, the non-numeric string can be put in the Release: field using the following syntax: %{X}.%{posttag} In this syntax, %{X} is the release number increment, and %{posttag} is the string that came from the version. Here, the period '.' should be used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters should appear in the Release field. Example (complicated post-release): foo-1.1.0-0.1.BETA (this is a prerelease, first beta) foo-1.1.0-0.2.BETA1 (this is a prerelease, second beta) foo-1.1.0-0.3.BETA2 (this is a prerelease, third beta) foo-1.1.0-0.4.CR1 (this is a prerelease, candidate release 1) foo-1.1.0-0.5.CR2 (this is a prerelease, candidate release 2) foo-1.1.0-1 (final release) foo-1.1.0-2.GA1 (post release, GA1) foo-1.1.0-3.CP1 (post release, CP1, after GA1) foo-1.1.0-4.CP2 (post release, CP2, after CP1) foo-1.1.0-5.SP1 (post release, SP1, after CP2) foo-1.1.0-6.SP1_CP1 (post release, SP1_CP1, after SP1) It is important to be careful with the post-release scheme, to ensure that package ordering is correct. It may be necessary to use Epoch to ensure that the current package is considered newer than the previous package. In such cases, the packager should try to convince upstream to be more reasonable with their post-release versioning. Also, packagers using the post-release scheme should put a comment in their spec file with a brief description of the upstream conventions for naming/versioning that are being worked around. This change was approved by the Fedora Packaging Committee and ratified by FESCO. ~spot From tcallawa at redhat.com Mon Apr 9 22:05:09 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 09 Apr 2007 17:05:09 -0500 Subject: [GuidelinesChange] Prepping BuildRoot For %install Message-ID: <1176156309.3970.59.camel@localhost.localdomain> An additional item has been added to the Packaging/Guidelines (as a subsection to BuildRoot): Prepping BuildRoot For %install It is important to properly prepare the BuildRoot in the %install section of your package before it is used. Every Fedora package MUST have an %install section that begins with either: %install rm -rf %{buildroot} or %install rm -rf $RPM_BUILD_ROOT This is to ensure that the BuildRoot will be created fresh during the %install section. Also, the following has been added to Packaging/ReviewGuidelines: - MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). See Prepping BuildRoot For %install for details. This change was approved by the Fedora Packaging Committee and ratified by FESCO. ~spot From tgl at redhat.com Tue Apr 10 03:44:07 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 09 Apr 2007 23:44:07 -0400 Subject: [GuidelinesChange] Prepping BuildRoot For %install In-Reply-To: <1176156309.3970.59.camel@localhost.localdomain> References: <1176156309.3970.59.camel@localhost.localdomain> Message-ID: <17116.1176176647@sss.pgh.pa.us> "Tom \"spot\" Callaway" writes: > It is important to properly prepare the BuildRoot in the %install > section of your package before it is used. Every Fedora package MUST > have an %install section that begins with either: > %install > rm -rf %{buildroot} > or > %install > rm -rf $RPM_BUILD_ROOT Just outta curiosity, why is it not considered an RPM bug that every specfile has to take care of this detail? Seems like it'd be trivial to fix it once instead of memorializing this oversight in every package till the end of time. regards, tom lane From panemade at gmail.com Tue Apr 10 04:07:25 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 10 Apr 2007 09:37:25 +0530 Subject: check-buildroot and check-rpaths to redhat-rpm-config? In-Reply-To: <200704092210.09991.ville.skytta@iki.fi> References: <200704092210.09991.ville.skytta@iki.fi> Message-ID: Hi, On 4/10/07, Ville Skytt? wrote: > Hello, > > Now that there's activity on the buildsys-macros/redhat-rpm-config front, > would it be possible to move the following scripts from rpmdevtools to one of > those packages? > > /usr/lib/rpm/check-buildroot > /usr/lib/rpm/check-rpaths > /usr/lib/rpm/check-rpaths-worker I saw few core packages(that I reviewed) and many new packages coming are also having rpath issues and making these scripts as part of redhat-rpm-config package is a really a good thing then. > > The reason for this is that I'd like to add some new utilities to rpmdevtools > which come with some new dependencies, and I don't think it's good to have > the base buildsys package set grow because of those. And those check-* > scripts fit better in redhat-rpm-config IMO. > > Another approach could be to split those scripts in a rpmdevtools subpackage, > or move them to a buildsys-* package that is shipped in the normal repos. I think we can consider this approach. > > Moving them away from rpmdevtools and rpmdevtools away from the base package > set would also allow purging a few things that get pulled in just because of > some rpmdevtools dependencies that aren't really relevant in build roots. > > Opinions? > > -- Regards, Parag. From panemade at gmail.com Tue Apr 10 03:54:36 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 10 Apr 2007 09:24:36 +0530 Subject: [GuidelinesChange] Prepping BuildRoot For %install In-Reply-To: <17116.1176176647@sss.pgh.pa.us> References: <1176156309.3970.59.camel@localhost.localdomain> <17116.1176176647@sss.pgh.pa.us> Message-ID: Hi, On 4/10/07, Tom Lane wrote: > "Tom \"spot\" Callaway" writes: > > It is important to properly prepare the BuildRoot in the %install > > section of your package before it is used. Every Fedora package MUST > > have an %install section that begins with either: > > %install > > rm -rf %{buildroot} > > or > > %install > > rm -rf $RPM_BUILD_ROOT > > Just outta curiosity, why is it not considered an RPM bug that every > specfile has to take care of this detail? Seems like it'd be trivial > to fix it once instead of memorializing this oversight in every package > till the end of time. To less up your work on checking whats mandatory things are missing from a SPEC file, you can use rpmdevtools package in extras. This package gives you fedora-newrpmspec command that will generate default template with necessary fields/tags that should be present in SPEC file. Regards, Parag. From pmatilai at laiskiainen.org Tue Apr 10 06:23:48 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 10 Apr 2007 09:23:48 +0300 (EEST) Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <4618E08B.9020300@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> Message-ID: On Sun, 8 Apr 2007, Rahul Sundaram wrote: > Hi > > The current thinking seems to be to just ignore them* but this is guaranteed > to result in a lot of confusion. When end users do a distribution upgrade via > yum or Anaconda, some of the packages might not have been updated to the > Fedora 7 version due to incorrect packaging or other issues while the rest > are packages which are deliberated not rebuild to avoid churn. Debugging a > end user system with such a mix of packages is very painful. Dist tags considered harmful... :) RHEL 5 suffers from this same syndrome, it has loads of packages tagged "fc6" which I could imagine causing quite a bit of confusion as well. - Panu - From fedora at leemhuis.info Tue Apr 10 06:33:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 10 Apr 2007 08:33:23 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: References: <4618E08B.9020300@fedoraproject.org> Message-ID: <461B2FB3.2030304@leemhuis.info> On 10.04.2007 08:23, Panu Matilainen wrote: > On Sun, 8 Apr 2007, Rahul Sundaram wrote: >> The current thinking seems to be to just ignore them* but this is guaranteed >> to result in a lot of confusion. When end users do a distribution upgrade via >> yum or Anaconda, some of the packages might not have been updated to the >> Fedora 7 version due to incorrect packaging or other issues while the rest >> are packages which are deliberated not rebuild to avoid churn. Debugging a >> end user system with such a mix of packages is very painful. > > Dist tags considered harmful... :) RHEL 5 suffers from this same > syndrome, it has loads of packages tagged "fc6" which I could imagine > causing quite a bit of confusion as well. Yeah, they made it a FAQ already ;-) http://kbase.redhat.com/faq/FAQ_103_10269.shtm CU thl From Axel.Thimm at ATrpms.net Tue Apr 10 07:08:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 09:08:55 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: References: <4618E08B.9020300@fedoraproject.org> Message-ID: <20070410070855.GB12110@neu.nirvana> On Tue, Apr 10, 2007 at 09:23:48AM +0300, Panu Matilainen wrote: > On Sun, 8 Apr 2007, Rahul Sundaram wrote: > >The current thinking seems to be to just ignore them* but this is > >guaranteed to result in a lot of confusion. When end users do a > >distribution upgrade via yum or Anaconda, some of the packages might not > >have been updated to the Fedora 7 version due to incorrect packaging or > >other issues while the rest are packages which are deliberated not rebuild > >to avoid churn. Debugging a end user system with such a mix of packages is > >very painful. > > Dist tags considered harmful... :) RHEL 5 suffers from this same > syndrome, it has loads of packages tagged "fc6" which I could imagine > causing quite a bit of confusion as well. Well, less confusion than surprised customers that would expect RHEL to go through the rebuilding of these packages and test the result instead of Fear-Of-Rebuilds. I wonder if RHEL even carries all required build dependencies to rebuild such a package. If not, it will be fun for the packager doing the bugfix/security update. -- 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 07:28:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 10 Apr 2007 09:28:57 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <4618E08B.9020300@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> Message-ID: <20070410072857.GC12110@neu.nirvana> On Sun, Apr 08, 2007 at 06:01:07PM +0530, Rahul Sundaram wrote: > The current thinking seems to be to just ignore them* but this is > guaranteed to result in a lot of confusion. Confusion is the lesser evil. The true evil is that the older the package's rebuild date the more different the build environment was, and the more likely a runtime or buildtime discrepancy may pop up. Yes, Matt does frequent rebuilds, but who tests them if they don't make it into rawhide? > I would suggest that we consider rebuilding just to avoid the confusion. > I consider that a good enough "technical reason". The advantage of less > churn in packages is lost quickly since packages receive updates fairly > quickly in general. The big packages have been rebuilt anyway, so there isn't much churn to save. I 100% agree with the rebuild suggestion, if it is not too late to do that. I'd even take a slip into account for that to happen. Also: The reason that there is no mass rebuild done is that the build tools did not change, but FC6 F7 gcc 4.1.1-30 4.1.2-8 glibc 2.5-3 2.5.90-20 binutils 2.17.50.0.3-6 2.17.50.0.12-3 Perhaps the gcc or binutils changes are not that big, but the glibc ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking the API (the glibc-headers) gives: 41 files changed, 297 insertions(+), 220 deletions(-) -- 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 mastahnke at gmail.com Tue Apr 10 12:32:13 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 10 Apr 2007 07:32:13 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <461B2FB3.2030304@leemhuis.info> References: <4618E08B.9020300@fedoraproject.org> <461B2FB3.2030304@leemhuis.info> Message-ID: <7874d9dd0704100532o745c4116u704554f5d80d901b@mail.gmail.com> On 4/10/07, Thorsten Leemhuis wrote: > On 10.04.2007 08:23, Panu Matilainen wrote: > > On Sun, 8 Apr 2007, Rahul Sundaram wrote: > >> The current thinking seems to be to just ignore them* but this is guaranteed > >> to result in a lot of confusion. When end users do a distribution upgrade via > >> yum or Anaconda, some of the packages might not have been updated to the > >> Fedora 7 version due to incorrect packaging or other issues while the rest > >> are packages which are deliberated not rebuild to avoid churn. Debugging a > >> end user system with such a mix of packages is very painful. > > > > Dist tags considered harmful... :) RHEL 5 suffers from this same > > syndrome, it has loads of packages tagged "fc6" which I could imagine > > causing quite a bit of confusion as well. > > Yeah, they made it a FAQ already ;-) > http://kbase.redhat.com/faq/FAQ_103_10269.shtm > As a paying RHEL customer, this kind of upsets me. They can't take the time to ensure file-names are right on their flagship product. I realize it's mostly cosmetic, but many people who run RHEL are NOT good at Linux and need all the help they can get. I think dist tags should match the dist the package is used in. End of story. MIKE > CU > thl > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From jwboyer at jdub.homelinux.org Tue Apr 10 12:39:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 10 Apr 2007 07:39:20 -0500 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <7874d9dd0704100532o745c4116u704554f5d80d901b@mail.gmail.com> References: <4618E08B.9020300@fedoraproject.org> <461B2FB3.2030304@leemhuis.info> <7874d9dd0704100532o745c4116u704554f5d80d901b@mail.gmail.com> Message-ID: <1176208760.3040.1.camel@zod.rchland.ibm.com> On Tue, 2007-04-10 at 07:32 -0500, Michael Stahnke wrote: > > > Dist tags considered harmful... :) RHEL 5 suffers from this same > > > syndrome, it has loads of packages tagged "fc6" which I could imagine > > > causing quite a bit of confusion as well. > > > > Yeah, they made it a FAQ already ;-) > > http://kbase.redhat.com/faq/FAQ_103_10269.shtm > > > > As a paying RHEL customer, this kind of upsets me. They can't take > the time to ensure file-names are right on their flagship product. I > realize it's mostly cosmetic, but many people who run RHEL are NOT > good at Linux and need all the help they can get. > > I think dist tags should match the dist the package is used in. End of story. Please don't whine about RHEL on this list. File a bug or contact Red Hat directly if you're pissed about something that was done in RHEL. Whining about it here will not result in magical changes being done to fix your issue. End of story. ;) josh From sgrubb at redhat.com Tue Apr 10 12:50:43 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 10 Apr 2007 08:50:43 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <4618E08B.9020300@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> Message-ID: <200704100850.43150.sgrubb@redhat.com> On Sunday 08 April 2007 08:31, Rahul Sundaram wrote: > The current thinking seems to be to just ignore them* but this is > guaranteed to result in a lot of confusion. It should be very simple to write a tool that just modifies the internal data in the rpm to change the dist tag and rename the file. If you wanted to get fancy, it could even update cvs for the specfile and update the changelog section of the rpm as well. It may not be necessary to recompile everything if that is objectionable. My personal opinion is that we should rebuild every package at least once during every development cycle not only so that the tags are correct, but to make sure packages don't bit-rot as the tool chain improves. I'd rather have the churn and correctness than less to download and bit-rot. -Steve From buildsys at fedoraproject.org Tue Apr 10 13:02:03 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Apr 2007 09:02:03 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-10 Message-ID: <20070410130203.DC3C0152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) mr.ecik AT gmail.com: kadu FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) kadu: mr.ecik AT gmail.com FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From tjanouse at redhat.com Tue Apr 10 14:19:01 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Tue, 10 Apr 2007 16:19:01 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <7874d9dd0704100532o745c4116u704554f5d80d901b@mail.gmail.com> References: <4618E08B.9020300@fedoraproject.org> <461B2FB3.2030304@leemhuis.info> <7874d9dd0704100532o745c4116u704554f5d80d901b@mail.gmail.com> Message-ID: <20070410141901.GA25644@redhat.com> Hello, On Tue, Apr 10, 2007 at 07:32:13AM -0500, Michael Stahnke wrote: > As a paying RHEL customer, this kind of upsets me. They can't take > the time to ensure file-names are right on their flagship product. I The file names ARE right. -- TJ. (Brno, CZ), BaseOS, Red Hat From tcallawa at redhat.com Tue Apr 10 14:19:37 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Apr 2007 09:19:37 -0500 Subject: [GuidelinesChange] Prepping BuildRoot For %install In-Reply-To: <17116.1176176647@sss.pgh.pa.us> References: <1176156309.3970.59.camel@localhost.localdomain> <17116.1176176647@sss.pgh.pa.us> Message-ID: <1176214777.3970.68.camel@localhost.localdomain> On Mon, 2007-04-09 at 23:44 -0400, Tom Lane wrote: > "Tom \"spot\" Callaway" writes: > > It is important to properly prepare the BuildRoot in the %install > > section of your package before it is used. Every Fedora package MUST > > have an %install section that begins with either: > > %install > > rm -rf %{buildroot} > > or > > %install > > rm -rf $RPM_BUILD_ROOT > > Just outta curiosity, why is it not considered an RPM bug that every > specfile has to take care of this detail? Seems like it'd be trivial > to fix it once instead of memorializing this oversight in every package > till the end of time. This is absolutely an RPM bug. However, since RPM is riddled with bugs, we can either hope they get fixed, or work around them with guidelines until they get fixed. Historically, filing bugs against items like this have been futile since it would "change RPM's behavior", as broken as it may be. I've personally had my fun with trying to submit RPM patches, and I'm not interested in that sort of pain again. If you're motivated to get this fixed in Fedora's RPM, please, feel free. We'll be happy to remove any guidelines made obsolete by bugfixes. ~spot From sgrubb at redhat.com Tue Apr 10 14:50:25 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 10 Apr 2007 10:50:25 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070410141901.GA25644@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <7874d9dd0704100532o745c4116u704554f5d80d901b@mail.gmail.com> <20070410141901.GA25644@redhat.com> Message-ID: <200704101050.25511.sgrubb@redhat.com> On Tuesday 10 April 2007 10:19, Tomas Janousek wrote: > > As a paying RHEL customer, this kind of upsets me. ?They can't take > > the time to ensure file-names are right on their flagship product. ?I > > The file names ARE right. I would disagree. If I were a paying customer, I would expect all package names to match. If nothing else, it makes you feel like the toolchain that is in RHEL actually did something with the package in case you have to rebuild it yourself at some point. It also makes you feel that somebody actually spent a couple of minutes with it. I can also envision somebody asking an admin why they put FC6 files on their installation and how that affects support. Even though there is a KB article, they still have go look for it and have to prove it to other people. That is really a needless exercise. Same thing with Fedora. I can envision people thinking that there is a failed upgrade somehow that left FC6 files after the install. Again, a needless exercise. -Steve From skvidal at linux.duke.edu Tue Apr 10 14:55:08 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 10 Apr 2007 10:55:08 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <200704101050.25511.sgrubb@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <7874d9dd0704100532o745c4116u704554f5d80d901b@mail.gmail.com> <20070410141901.GA25644@redhat.com> <200704101050.25511.sgrubb@redhat.com> Message-ID: <1176216908.32458.44.camel@cutter> On Tue, 2007-04-10 at 10:50 -0400, Steve Grubb wrote: > On Tuesday 10 April 2007 10:19, Tomas Janousek wrote: > > > As a paying RHEL customer, this kind of upsets me. They can't take > > > the time to ensure file-names are right on their flagship product. I > > > > The file names ARE right. > > I would disagree. If I were a paying customer, I would expect all package > names to match. If nothing else, it makes you feel like the toolchain that is > in RHEL actually did something with the package in case you have to rebuild > it yourself at some point. It also makes you feel that somebody actually > spent a couple of minutes with it. > > I can also envision somebody asking an admin why they put FC6 files on their > installation and how that affects support. Even though there is a KB article, > they still have go look for it and have to prove it to other people. That is > really a needless exercise. Please take this to a rhel list. please. -sv From snecklifter at gmail.com Tue Apr 10 16:16:03 2007 From: snecklifter at gmail.com (Chris Brown) Date: Tue, 10 Apr 2007 17:16:03 +0100 Subject: Packages with "fc6" name in Fedora 7 Message-ID: <364d303b0704100916q3d083f66h9f29ac32d9f3964a@mail.gmail.com> > On Sunday 08 April 2007 08:31, Rahul Sundaram wrote: > > The current thinking seems to be to just ignore them* but this is > > guaranteed to result in a lot of confusion. > > It should be very simple to write a tool that just modifies the internal > data > in the rpm to change the dist tag and rename the file. If you wanted to > get > fancy, it could even update cvs for the specfile and update the changelog > section of the rpm as well. It may not be necessary to recompile > everything > if that is objectionable. > > My personal opinion is that we should rebuild every package at least once > during every development cycle not only so that the tags are correct, but > to > make sure packages don't bit-rot as the tool chain improves. I'd rather > have > the churn and correctness than less to download and bit-rot. > FWIW, +1. I don't think packages with fc6 tags should be associated in any way with f7. It will cause confusion. A prime example is my mythtv box which has now undergone two distro upgrades (flawlessly I might add) from FC4 > F5 > FC6. To get rid of old cruft and in my naivety I simply ran: $ rpm -qa | grep -i fc5 after upgrading to see what had been left behind and went through the process of removing and replacing these few packages. I do think a rebuild during every development cycle is a good idea for the reasons already mentioned above as well. More so in fact. Cheers Chris -- http://www.chruz.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Tue Apr 10 17:08:08 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 10:08:08 -0700 Subject: [GuidelinesChange] UTF8 filenames Message-ID: <1176224888.30783.20.camel@localhost.localdomain> A new Guideline has been added to the Encoding section: ''' Non-ASCII Filenames 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. ''' This change was approved by the Fedora Packaging Committee and ratified by FESCO. -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 nicolas.mailhot at laposte.net Tue Apr 10 17:17:43 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 10 Apr 2007 19:17:43 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176224888.30783.20.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> Message-ID: <1176225463.31387.1.camel@rousalka.dyndns.org> Le mardi 10 avril 2007 ? 10:08 -0700, Toshio Kuratomi a ?crit : > A new Guideline has been added to the Encoding section: > > ''' > Non-ASCII Filenames > 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. > ''' > > This change was approved by the Fedora Packaging Committee and ratified > by FESCO. Shouldn't this be clarified as 7-bit ASCII ? Many people think ASCII ~ 8-bit ISO-8859-1 Good ISO-8859-1 can be bad UTF-8 Regards, -- 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 Christian.Iseli at licr.org Tue Apr 10 17:18:01 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 10 Apr 2007 19:18:01 +0200 Subject: FYI - cvs-import.sh changes Message-ID: <20070410191801.530daf8a@ludwig-alpha.unil.ch> Hi folks, It was noticed that the cvs-import script gets used by many folks, not only for actually importing a new package into CVS, but also for importing new versions of an existing package. This latter usage led to a few cases where changes made in CVS got silently lost when the updated package was imported. After some discussions (like disallowing the use of cvs-import for anything else than initial import) it was decided to modify the script to at least show a diff of what's currently in CVS with what's going to be imported (so that there is a chance the maintainer will notice changes about to be undone), and will ask the maintainer to enter a commit message. Thanks to Jens Petersen for implementing the changes. Cheers, C From Christian.Iseli at licr.org Tue Apr 10 18:37:07 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 10 Apr 2007 20:37:07 +0200 Subject: FE Package Status of Apr 10, 2007 Message-ID: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> Hi folks, Yikes, this almost turns into a monthly thing... Sorry. I'm waiting for the dust to settle a bit wrt the merge and hope to update the script to track the whole of Fedora packages asap. (and then I'll need to tap into the pkgdb too :-) ) Cheers, C P.S. and yes, there really is a CVS module named isorelax-0-0.1.release20050331.1jpp.1.src.rpm oh hum... ---- FE Package Status of Apr 10, 2007 The full report can be found here: http://fedoraproject.org/wiki/Extras/PackageStatus Owners file stats: - 3161 packages - 4729 binary rpms in devel - 99 orphans - 24 packages not available in devel or release alexl at users dot sourceforge dot net perl-bioperl alexl at users dot sourceforge dot net perl-Bio-ASN1-EntrezGene andreas at bawue dot net ddrescue arnd at arndb dot de dtc bdpepple at ameritech dot net galago-filesystem dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils guillaume dot thouvenin at bull dot net elsa icon at fedoraproject dot org mod_evasive jhrozek at redhat dot com dwdiff mastahnke at gmail dot com epel-release mcepl at redhat dot com gstreamer-plugins-pulseaudio mtasaka at ioa dot s dot u-tokyo dot ac dot jp python-mecab otaylor at redhat dot com mugshot paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman tcallawa at redhat dot com perl-Mail-Box vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp wart at kobold dot org compat-guichan05 - 16 packages not available in devel but present in release Fedora at FamilleCollet dot com ocsinventory-ipdiscover alexl at users dot sourceforge dot net perl-SVG-Graph fabrice at bellet dot info fgfs-base fabrice at bellet dot info fgfs-Atlas fedora at leemhuis dot info websec jdieter at gmail dot com yum-presto jima at beer dot tclug dot org vblade jima at beer dot tclug dot org aoetools jmp at safe dot ca clement lmacken at redhat dot com python-TurboMail lxtnow at gmail dot com specto rnorwood at redhat dot com perl-RPM2 tcallawa at redhat dot com perl-Mail-Transport-Dbx tcallawa at redhat dot com perl-Template-GD tcallawa at redhat dot com perl-User-Identity tcallawa at redhat dot com perl-Object-Realize-Later - 7 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=212003,231303,232548 mugshot otaylor at redhat.com xmlunit pcheung at redhat.com gnome-yum allisson at gmail.com https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=221084,227091,231861,235136 dkms Matt_Domsch at dell.com objectweb-anttask rafaels at redhat.com cyrus-imapd tjanouse at redhat.com lostirc splinux25 at gmail.com - 2 packages present in the development repo which have no owners entry gstreamer-plugins-pulse ws-commons-util - 3 orphaned packages, yet available in extras devel libedit luks-tools udftools - 44 packages that moved to core FE-ACCEPT packages stats: - 2216 accepted, closed package reviews - 30 accepted, closed package reviews not in repo - 9 accepted, closed package reviews not in owners - 142 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 235 open tickets - 13 closed tickets FE-NEW packages stats: - 1091 open tickets - 36 closed tickets FE-NEEDSPONSOR packages stats: - 47 open tickets FE-LEGAL packages stats: - 1 open tickets FE-GUIDELINES packages stats: - open tickets OPEN-BUGS packages stats: - 26 open tickets - 13 tickets with no activity in eight weeks - 3 tickets with no activity in four weeks CVS stats: - 3160 packages with a devel directory - 4 packages with no owners entry gstreamer-plugins-pulse isorelax-0-0.1.release20050331.1jpp.1.src.rpm postgis tdma - 1 packages in CVS devel *and* Core libnl - 192 packages were dropped from extras Maintainers stats: - 295 maintainers - 2 inactive maintainers with open bugs - 50 inactive maintainers Dropped FC packages: - 190 packages were dropped from core since FC 3 Comps.xml files stats: - 1066 packages in comps-fe7 file - 1156 packages missing from comps-fe7 file - 12 packages in comps-fe7 but not in repo - 969 packages in comps-fe6 file - 622 packages missing from comps-fe6 file - 6 packages in comps-fe6 but not in repo From bugs.michael at gmx.net Tue Apr 10 19:06:15 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 10 Apr 2007 21:06:15 +0200 Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> Message-ID: <20070410210615.1b3b6648.bugs.michael@gmx.net> On Tue, 10 Apr 2007 20:37:07 +0200, Christian Iseli wrote: > - 24 packages not available in devel or release > otaylor at redhat dot com mugshot The mugshot builds are not pushed into the repo, but to a separate location. From jima at beer.tclug.org Tue Apr 10 19:26:23 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 10 Apr 2007 14:26:23 -0500 (CDT) Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> Message-ID: On Tue, 10 Apr 2007, Christian Iseli wrote: > - 16 packages not available in devel but present in release > jima at beer dot tclug dot org vblade > jima at beer dot tclug dot org aoetools Hmm, I think this is a false positive; I definitely see aoetools-15-1.fc7 and vblade-14-2.fc7 (once I found a synched mirror, anyway). Jima From sundaram at fedoraproject.org Tue Apr 10 20:13:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 11 Apr 2007 01:43:01 +0530 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: References: <4618E08B.9020300@fedoraproject.org> Message-ID: <461BEFCD.3090900@fedoraproject.org> Panu Matilainen wrote: > On Sun, 8 Apr 2007, Rahul Sundaram wrote: > >> Hi >> >> The current thinking seems to be to just ignore them* but this is >> guaranteed to result in a lot of confusion. When end users do a >> distribution upgrade via yum or Anaconda, some of the packages might >> not have been updated to the Fedora 7 version due to incorrect >> packaging or other issues while the rest are packages which are >> deliberated not rebuild to avoid churn. Debugging a end user system >> with such a mix of packages is very painful. > > Dist tags considered harmful... :) RHEL 5 suffers from this same > syndrome, it has loads of packages tagged "fc6" which I could imagine > causing quite a bit of confusion as well. Since you ask, this is one of the main reasons I said it is guaranteed to cause confusion. If anybody can calculate the amount of money Red Hat loses in having support people attend to such issues I would doubt they would consider it merely a cosmetic issue anymore. Rahul From cweyl at alumni.drew.edu Tue Apr 10 21:10:51 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 10 Apr 2007 14:10:51 -0700 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <1176153846.26544.36.camel@mortise.boston.redhat.com> References: <4618E08B.9020300@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> <200704082006.31849.opensource@till.name> <200704082116.24174.jkeating@redhat.com> <20070409022216.GA20485@jadzia.bu.edu> <461A7E84.6030801@redhat.com> <1176153846.26544.36.camel@mortise.boston.redhat.com> Message-ID: <7dd7ab490704101410p32792aablf8d6682d474e15fc@mail.gmail.com> On 4/9/07, David Cantrell wrote: > I do this for the stuff I maintain using scratch builds in brew. This > could easily be expanded to an X-line script that just always runs and > walks the CVS tree building whatever is the latest tag for devel for a > package. Hmm... You know, it shouldn't be too hard to set up "scratch" targets in the buildsys (plague, no idea about koji), mark them as "testing", and let people fire off builds against it without having to worry that those packages will ever be pushed anywhere. I could see that as being useful.... -Chris -- Chris Weyl Ex astris, scientia From chitlesh at fedoraproject.org Tue Apr 10 21:28:49 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 10 Apr 2007 23:28:49 +0200 Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <20070410210615.1b3b6648.bugs.michael@gmx.net> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> <20070410210615.1b3b6648.bugs.michael@gmx.net> Message-ID: <13dbfe4f0704101428x6967bf0by6f2d779852edd574@mail.gmail.com> On 4/10/07, Michael Schwendt wrote: > The mugshot builds are not pushed into the repo, but to a separate > location. Is there any specific reason for this ? Smolt is already inside, hopefully to see mugshot as well. Chitlesh -- http://clunixchit.blogspot.com From Christian.Iseli at licr.org Tue Apr 10 21:57:32 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 10 Apr 2007 23:57:32 +0200 Subject: FE Package Status of Apr 10, 2007 In-Reply-To: References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> Message-ID: <20070410235732.1afe165d@ludwig-alpha.unil.ch> On Tue, 10 Apr 2007 14:26:23 -0500 (CDT), Jima wrote: > Hmm, I think this is a false positive; I definitely see aoetools-15-1.fc7 > and vblade-14-2.fc7 (once I found a synched mirror, anyway). Could well be. I check pkgs from http://mirrors.kernel.org/fedora (for some reason I can't remember)... Cheers, C From Christian.Iseli at licr.org Tue Apr 10 21:59:38 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 10 Apr 2007 23:59:38 +0200 Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <20070410210615.1b3b6648.bugs.michael@gmx.net> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> <20070410210615.1b3b6648.bugs.michael@gmx.net> Message-ID: <20070410235938.65af5752@ludwig-alpha.unil.ch> On Tue, 10 Apr 2007 21:06:15 +0200, Michael Schwendt wrote: > The mugshot builds are not pushed into the repo, but to a separate > location. k, I'll tag them as special for now. Thanks, C From tcallawa at redhat.com Tue Apr 10 22:08:51 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 10 Apr 2007 17:08:51 -0500 Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <20070410235732.1afe165d@ludwig-alpha.unil.ch> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> <20070410235732.1afe165d@ludwig-alpha.unil.ch> Message-ID: <1176242931.3970.93.camel@localhost.localdomain> On Tue, 2007-04-10 at 23:57 +0200, Christian Iseli wrote: > On Tue, 10 Apr 2007 14:26:23 -0500 (CDT), Jima wrote: > > Hmm, I think this is a false positive; I definitely see aoetools-15-1.fc7 > > and vblade-14-2.fc7 (once I found a synched mirror, anyway). > > Could well be. I check pkgs from http://mirrors.kernel.org/fedora (for > some reason I can't remember)... All of the packages of mine on that section are also false positives, they definitely built in devel as well. ~spot From dennis at ausil.us Tue Apr 10 22:15:08 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Apr 2007 17:15:08 -0500 Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <20070410235732.1afe165d@ludwig-alpha.unil.ch> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> <20070410235732.1afe165d@ludwig-alpha.unil.ch> Message-ID: <200704101715.08722.dennis@ausil.us> On Tuesday 10 April 2007 04:57:32 pm Christian Iseli wrote: > On Tue, 10 Apr 2007 14:26:23 -0500 (CDT), Jima wrote: > > Hmm, I think this is a false positive; I definitely see aoetools-15-1.fc7 > > and vblade-14-2.fc7 (once I found a synched mirror, anyway). > > Could well be. I check pkgs from http://mirrors.kernel.org/fedora (for > some reason I can't remember)... > > Cheers, > C I saw a conversation a week or two back that mirrors.kernel.org was migrating their mirrors from ext3 to xfs. I'm guessing that they are not syncing new content while the migration takes place. -- Dennis Gilmore, RHCE From a.badger at gmail.com Tue Apr 10 22:16:23 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 15:16:23 -0700 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176225463.31387.1.camel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> Message-ID: <1176243383.30783.76.camel@localhost.localdomain> On Tue, 2007-04-10 at 19:17 +0200, Nicolas Mailhot wrote: > Le mardi 10 avril 2007 ? 10:08 -0700, Toshio Kuratomi a ?crit : > > A new Guideline has been added to the Encoding section: > > > > ''' > > Non-ASCII Filenames > > 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. > > ''' > > > > This change was approved by the Fedora Packaging Committee and ratified > > by FESCO. > > Shouldn't this be clarified as 7-bit ASCII ? Many people think ASCII ~ > 8-bit ISO-8859-1 > I think of ASCII != ISO-8859-1 but if that's not a common way of thinking then I am more than willing to clarify. I notice that we use the term US-ASCII in the outer section:: http://fedoraproject.org/wiki/Packaging/Guidelines#PackageEncoding Would changing non-ASCII to non-US-ASCII characters be suffcient? -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 mclasen at redhat.com Tue Apr 10 22:29:45 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 11 Apr 2007 00:29:45 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176243383.30783.76.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> Message-ID: <1176244185.2976.1.camel@localhost.localdomain> On Tue, 2007-04-10 at 15:16 -0700, Toshio Kuratomi wrote: > On Tue, 2007-04-10 at 19:17 +0200, Nicolas Mailhot wrote: > > Le mardi 10 avril 2007 ? 10:08 -0700, Toshio Kuratomi a ?crit : > > > A new Guideline has been added to the Encoding section: > > > > > > ''' > > > Non-ASCII Filenames > > > 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. > > > ''' > > > > > > This change was approved by the Fedora Packaging Committee and ratified > > > by FESCO. > > > > Shouldn't this be clarified as 7-bit ASCII ? Many people think ASCII ~ > > 8-bit ISO-8859-1 > > > I think of ASCII != ISO-8859-1 but if that's not a common way of > thinking then I am more than willing to clarify. > > I notice that we use the term US-ASCII in the outer section:: > http://fedoraproject.org/wiki/Packaging/Guidelines#PackageEncoding > > Would changing non-ASCII to non-US-ASCII characters be suffcient? > US-ASCII is a meaningless term. There simply is no 8-bit ASCII (neither is there US-ASCII or non-US-ASCII). If you really need to clarify the meaning of ASCII here, I'd simply refer to "man ascii". From nicolas.mailhot at laposte.net Tue Apr 10 22:37:50 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 00:37:50 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176243383.30783.76.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> Message-ID: <1176244670.18654.15.camel@rousalka.dyndns.org> Le mardi 10 avril 2007 ? 15:16 -0700, Toshio Kuratomi a ?crit : > On Tue, 2007-04-10 at 19:17 +0200, Nicolas Mailhot wrote: > > Le mardi 10 avril 2007 ? 10:08 -0700, Toshio Kuratomi a ?crit : > > > A new Guideline has been added to the Encoding section: > > > > > > ''' > > > Non-ASCII Filenames > > > 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. > > > ''' > > > > > > This change was approved by the Fedora Packaging Committee and ratified > > > by FESCO. > > > > Shouldn't this be clarified as 7-bit ASCII ? Many people think ASCII ~ > > 8-bit ISO-8859-1 > > > I think of ASCII != ISO-8859-1 but if that's not a common way of > thinking then I am more than willing to clarify. > > I notice that we use the term US-ASCII in the outer section:: > http://fedoraproject.org/wiki/Packaging/Guidelines#PackageEncoding > > Would changing non-ASCII to non-US-ASCII characters be suffcient? Why don't you just say: Every filename must be encoded as UTF-8. Filenames using characters outside the range 0000?007F as defined in page 2 of http://www.unicode.org/charts/PDF/U0000.pdf may need conversion. -- 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 nicolas.mailhot at laposte.net Tue Apr 10 22:39:29 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 00:39:29 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176244185.2976.1.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244185.2976.1.camel@localhost.localdomain> Message-ID: <1176244769.18654.18.camel@rousalka.dyndns.org> Le mercredi 11 avril 2007 ? 00:29 +0200, Matthias Clasen a ?crit : > US-ASCII is a meaningless term. There simply is no 8-bit ASCII Sure but ASCII is frequently abused nevertheless. And human lazyness will "help" people choose the abusive interpretation. -- 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 a.badger at gmail.com Wed Apr 11 00:07:55 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 17:07:55 -0700 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176244670.18654.15.camel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> Message-ID: <1176250075.30783.91.camel@localhost.localdomain> On Wed, 2007-04-11 at 00:37 +0200, Nicolas Mailhot wrote: > Le mardi 10 avril 2007 ? 15:16 -0700, Toshio Kuratomi a ?crit : > > On Tue, 2007-04-10 at 19:17 +0200, Nicolas Mailhot wrote: > > > Le mardi 10 avril 2007 ? 10:08 -0700, Toshio Kuratomi a ?crit : > > > > A new Guideline has been added to the Encoding section: > > > > > > > > ''' > > > > Non-ASCII Filenames > > > > 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. > > > > ''' > > > > > > > > This change was approved by the Fedora Packaging Committee and ratified > > > > by FESCO. > > > > > > Shouldn't this be clarified as 7-bit ASCII ? Many people think ASCII ~ > > > 8-bit ISO-8859-1 > > > > > I think of ASCII != ISO-8859-1 but if that's not a common way of > > thinking then I am more than willing to clarify. > > > > I notice that we use the term US-ASCII in the outer section:: > > http://fedoraproject.org/wiki/Packaging/Guidelines#PackageEncoding > > > > Would changing non-ASCII to non-US-ASCII characters be suffcient? > > Why don't you just say: > > Every filename must be encoded as UTF-8. Filenames using characters > outside the range 0000?007F as defined in page 2 of > http://www.unicode.org/charts/PDF/U0000.pdf may need conversion. Because I think more people will understand what ASCII means than U0000.pdf? I (don't like this either but) would rather leave it as is and link to the wikipedia article for ASCII. I like the simplicity of "Every filename must be encoded as UTF-8." But if we just leave it at that some people in "ASCII speaking countries" are sure to ask, "So how do I convert ASCII to UTF-8?" Maybe something like: ''' Encoding Unless you need to use characters outside the [:http://en.wikipedia.org/wiki/ASCII: ASCII repertoire] (the 128 characters that consist of letters, numbers and punctuation used in English), 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. 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 wart at kobold.org Wed Apr 11 00:47:21 2007 From: wart at kobold.org (Michael Thomas) Date: Tue, 10 Apr 2007 17:47:21 -0700 Subject: yum-3.0.5 bug - [Was : Mock builds borked for libgl} Message-ID: <461C3019.6050308@kobold.org> Seth wrote: > On Sat, 2007-04-07 at 15:15 +0200, Remi Collet wrote: > > Remi Collet a ?crit : > > > Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from core. > > > > Revert back to yum-3.0.3 solves the issue. > > > > Take a look in updates-testing at yum-3.0.5-2.fc6 - I think it solves > this one. > > thanks, > -sv Is this fix going to be pushed to the Fedora builders? I'm currently hitting the same libgl problem that Chris originally reported: http://buildsys.fedoraproject.org/logs/fedora-6-extras/31361-compat-guichan05-0.5.0-4.fc6/x86_64/root.log --Wart From skvidal at linux.duke.edu Wed Apr 11 01:01:28 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 10 Apr 2007 21:01:28 -0400 Subject: yum-3.0.5 bug - [Was : Mock builds borked for libgl} In-Reply-To: <461C3019.6050308@kobold.org> References: <461C3019.6050308@kobold.org> Message-ID: <1176253288.32458.75.camel@cutter> On Tue, 2007-04-10 at 17:47 -0700, Michael Thomas wrote: > Seth wrote: > > On Sat, 2007-04-07 at 15:15 +0200, Remi Collet wrote: > > > Remi Collet a ?crit : > > > > Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from > core. > > > > > > Revert back to yum-3.0.3 solves the issue. > > > > > > > Take a look in updates-testing at yum-3.0.5-2.fc6 - I think it solves > > this one. > > > > thanks, > > -sv > > Is this fix going to be pushed to the Fedora builders? I'm currently > hitting the same libgl problem that Chris originally reported: > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/31361-compat-guichan05-0.5.0-4.fc6/x86_64/root.log > the package is updates-testing and should go out to updates before long - but ask the buildsystem keepers. -sv From jima at beer.tclug.org Wed Apr 11 04:38:40 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 10 Apr 2007 23:38:40 -0500 (CDT) Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <20070410235732.1afe165d@ludwig-alpha.unil.ch> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> <20070410235732.1afe165d@ludwig-alpha.unil.ch> Message-ID: On Tue, 10 Apr 2007, Christian Iseli wrote: > On Tue, 10 Apr 2007 14:26:23 -0500 (CDT), Jima wrote: >> Hmm, I think this is a false positive; I definitely see aoetools-15-1.fc7 >> and vblade-14-2.fc7 (once I found a synched mirror, anyway). Yeah, as Dennis said, they don't seem to be currently synched for devel. > Could well be. I check pkgs from http://mirrors.kernel.org/fedora (for > some reason I can't remember)... Probably because it's almost always a fast, synchronized mirror. This is just the "almost" part. :-) Jima From peter at thecodergeek.com Wed Apr 11 05:51:04 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 10 Apr 2007 22:51:04 -0700 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176250075.30783.91.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> Message-ID: <1176270664.11405.2.camel@tuxhugs> On Tue, 2007-04-10 at 17:07 -0700, Toshio Kuratomi wrote: > I like the simplicity of "Every filename must be encoded as UTF-8." But > if we just leave it at that some people in "ASCII speaking countries" > are sure to ask, "So how do I convert ASCII to UTF-8?" Maybe something > like: Well, UTF-8 is a full superset of ASCII; so simply stating that "Every filename must be encoded as UTF-8" would mean that any ASCII-only filenames are inherently acceptable. We could add a clarification, of course, such as something to the effect of: "Please note that UTF-8 is a superset of ASCII, thus ASCII-only filenames are also acceptable." Thanks. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 caillon at redhat.com Wed Apr 11 06:09:03 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 11 Apr 2007 02:09:03 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <7dd7ab490704101410p32792aablf8d6682d474e15fc@mail.gmail.com> References: <4618E08B.9020300@fedoraproject.org> <20070408174635.GA20424@jadzia.bu.edu> <200704082006.31849.opensource@till.name> <200704082116.24174.jkeating@redhat.com> <20070409022216.GA20485@jadzia.bu.edu> <461A7E84.6030801@redhat.com> <1176153846.26544.36.camel@mortise.boston.redhat.com> <7dd7ab490704101410p32792aablf8d6682d474e15fc@mail.gmail.com> Message-ID: <461C7B7F.7080804@redhat.com> Chris Weyl wrote: > On 4/9/07, David Cantrell wrote: >> I do this for the stuff I maintain using scratch builds in brew. This >> could easily be expanded to an X-line script that just always runs and >> walks the CVS tree building whatever is the latest tag for devel for a >> package. > > Hmm... You know, it shouldn't be too hard to set up "scratch" targets > in the buildsys (plague, no idea about koji), mark them as "testing", > and let people fire off builds against it without having to worry that > those packages will ever be pushed anywhere. I could see that as > being useful.... This is something that we should automate. Just because maintainers might be too lazy to do rebuilds themselves doesn't mean we shouldn't try to find bugs in their required libraries, etc. Plus with automation, we can schedule and/or order how frequently packages get rebuilt so we can avoid overloading the service if for whatever reason everyone decides to do scratch builds at once. We can even include logic such as "hey, there's a new version of mono, let's rebuild all mono apps just to make sure the new version doesn't break things" From nicolas.mailhot at laposte.net Wed Apr 11 06:14:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 08:14:14 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176250075.30783.91.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> Message-ID: <1176272054.24284.6.camel@rousalka.dyndns.org> Le mardi 10 avril 2007 ? 17:07 -0700, Toshio Kuratomi a ?crit : > On Wed, 2007-04-11 at 00:37 +0200, Nicolas Mailhot wrote: > > Every filename must be encoded as UTF-8. Filenames using characters > > outside the range 0000?007F as defined in page 2 of > > http://www.unicode.org/charts/PDF/U0000.pdf may need conversion. > > Because I think more people will understand what ASCII means than > U0000.pdf? Page 2 of the linked pdf is a glyph chart which in my experience people understand way more easily than ASCII (even with added textual explanations) > Encoding > Unless you need to use characters outside the > [:http://en.wikipedia.org/wiki/ASCII: ASCII repertoire] the wikipedia article is too long and dense, people will zap it > (the 128 > characters that consist of letters, numbers and punctuation used in > English), This may seem clear to you because you know what it means, but that's not so for the average non-english-speaking packager. They'll assume the 128 characters include latin variants (or ?), and forget about control codes and punctuation. Regards, -- 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 bugs.michael at gmx.net Wed Apr 11 06:39:08 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 11 Apr 2007 08:39:08 +0200 Subject: FE Package Status of Apr 10, 2007 In-Reply-To: <13dbfe4f0704101428x6967bf0by6f2d779852edd574@mail.gmail.com> References: <20070410203707.3defcbfb@ludwig-alpha.unil.ch> <20070410210615.1b3b6648.bugs.michael@gmx.net> <13dbfe4f0704101428x6967bf0by6f2d779852edd574@mail.gmail.com> Message-ID: <20070411083908.d326afaf.bugs.michael@gmx.net> On Tue, 10 Apr 2007 23:28:49 +0200, Chitlesh GOORAH wrote: > On 4/10/07, Michael Schwendt wrote: > > The mugshot builds are not pushed into the repo, but to a separate > > location. > > Is there any specific reason for this ? Yes, to make it easier for the mugshot group to update server and client at once. From a.badger at gmail.com Wed Apr 11 06:37:57 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 23:37:57 -0700 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176270664.11405.2.camel@tuxhugs> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176270664.11405.2.camel@tuxhugs> Message-ID: <1176273477.30783.167.camel@localhost.localdomain> On Tue, 2007-04-10 at 22:51 -0700, Peter Gordon wrote: > On Tue, 2007-04-10 at 17:07 -0700, Toshio Kuratomi wrote: > > I like the simplicity of "Every filename must be encoded as UTF-8." But > > if we just leave it at that some people in "ASCII speaking countries" > > are sure to ask, "So how do I convert ASCII to UTF-8?" Maybe something > > like: > > Well, UTF-8 is a full superset of ASCII; so simply stating that "Every > filename must be encoded as UTF-8" would mean that any ASCII-only > filenames are inherently acceptable. We could add a clarification, of > course, such as something to the effect of: "Please note that UTF-8 is a > superset of ASCII, thus ASCII-only filenames are also acceptable." > Except that Nicolas's arguments about people in ISO-8859-1 speaking countries assuming ASCII includes accented Roman characters would apply to that note as well. Really, I don't think there's any way to clarify this without defining what ASCII is. In a few (and by few, I mean five to ten :-) years everyone will know what UTF-8 is and we won't have to worry about people who think that ASCII has to be converted into UTF-8. -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 devrim at CommandPrompt.com Wed Apr 11 06:39:28 2007 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Wed, 11 Apr 2007 09:39:28 +0300 Subject: Looking for reviewers In-Reply-To: <1174868341.4352.5.camel@laptop.gunduz.org> References: <1174868341.4352.5.camel@laptop.gunduz.org> Message-ID: <1176273568.3055.7.camel@laptop.gunduz.org> Hi, On Mon, 2007-03-26 at 03:19 +0300, Devrim G?ND?Z wrote: > > I'm looking for reviewers for these 3 PostgreSQL related packages: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229321 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229322 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229323 Still looking for reviewers... Also I submitted another one yesterday. This is ODBCng package for PostgreSQL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235929 Regards, -- Devrim G?ND?Z PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Wed Apr 11 06:55:23 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 10 Apr 2007 23:55:23 -0700 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176272054.24284.6.camel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> Message-ID: <1176274523.30783.183.camel@localhost.localdomain> On Wed, 2007-04-11 at 08:14 +0200, Nicolas Mailhot wrote: > Le mardi 10 avril 2007 ? 17:07 -0700, Toshio Kuratomi a ?crit : > > On Wed, 2007-04-11 at 00:37 +0200, Nicolas Mailhot wrote: > > > > Every filename must be encoded as UTF-8. Filenames using characters > > > outside the range 0000?007F as defined in page 2 of > > > http://www.unicode.org/charts/PDF/U0000.pdf may need conversion. > > > > Because I think more people will understand what ASCII means than > > U0000.pdf? > > Page 2 of the linked pdf is a glyph chart which in my experience people > understand way more easily than ASCII (even with added textual > explanations) > the wikipedia article is too long and dense, people will zap it > Then we link to http://en.wikipedia.org/wiki/Image:ASCII_full.svg > > (the 128 > > characters that consist of letters, numbers and punctuation used in > > English), > > This may seem clear to you because you know what it means, but that's > not so for the average non-english-speaking packager. They'll assume the > 128 characters include latin variants (or ?), and forget about control > codes and punctuation. > We could define it as a negative "(ASCII does not include accented letters or special symbols like ?)". Basically, I think a good portion of anglo-centric packagers won't know what the relationship is between ASCII and UTF-8. So there needs to be some note that says that ASCII-only text is fine. If you think that non-English speaking packagers won't know what ASCII is then we need to define ASCII for them. I'm willing to make these two points with whatever wording you like as long as it's clear both points are addressed. -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 nicolas.mailhot at laposte.net Wed Apr 11 07:48:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 09:48:57 +0200 (CEST) Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176274523.30783.183.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> Message-ID: <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> Le Mer 11 avril 2007 08:55, Toshio Kuratomi a ?crit : > On Wed, 2007-04-11 at 08:14 +0200, Nicolas Mailhot wrote: >> Le mardi 10 avril 2007 ? 17:07 -0700, Toshio Kuratomi a ?crit : >> > On Wed, 2007-04-11 at 00:37 +0200, Nicolas Mailhot wrote: >> >> > > Every filename must be encoded as UTF-8. Filenames using characters >> > > outside the range 0000?007F as defined in page 2 of >> > > http://www.unicode.org/charts/PDF/U0000.pdf may need conversion. >> > >> > Because I think more people will understand what ASCII means than >> > U0000.pdf? >> >> Page 2 of the linked pdf is a glyph chart which in my experience people >> understand way more easily than ASCII (even with added textual >> explanations) > >> the wikipedia article is too long and dense, people will zap it >> > Then we link to http://en.wikipedia.org/wiki/Image:ASCII_full.svg This will be fine http://en.wikipedia.org/wiki/ASCII#ASCII_printable_characters may work too (although the text before the table may be confusing) > We could define it as a negative "(ASCII does not include accented > letters or special symbols like ?)". Been there, tried that, anything but a chart or an image like the one you proposed is not a sufficient cluestick > Basically, I think a good portion of anglo-centric packagers won't know > what the relationship is between ASCII and UTF-8. Sure. But a good portion of anglo-centric packagers won't know what ASCII is either. Try to poll people someday you'll be surprised. Regards, -- Nicolas Mailhot From gbenson at redhat.com Wed Apr 11 08:29:49 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 11 Apr 2007 09:29:49 +0100 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> Message-ID: <20070411082949.GA3863@redhat.com> Nicolas Mailhot wrote: > Le Mer 11 avril 2007 08:55, Toshio Kuratomi a ?crit : > > We could define it as a negative "(ASCII does not include accented > > letters or special symbols like ?)". > > Been there, tried that, anything but a chart or an image like the > one you proposed is not a sufficient cluestick Whatever we say, why not back that up with a check in rpmbuild? Like the _unpackaged_files_terminate_build one? One of the features of UTF-8 is that you can distinguish it from non-UTF-8 with a decent probability of success. Cheers, Gary From j.w.r.degoede at hhs.nl Wed Apr 11 08:49:38 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 11 Apr 2007 10:49:38 +0200 Subject: Looking for reviewers In-Reply-To: <1176273568.3055.7.camel@laptop.gunduz.org> References: <1174868341.4352.5.camel@laptop.gunduz.org> <1176273568.3055.7.camel@laptop.gunduz.org> Message-ID: <461CA122.4030202@hhs.nl> Devrim G?ND?Z wrote: > Hi, > > On Mon, 2007-03-26 at 03:19 +0300, Devrim G?ND?Z wrote: >> I'm looking for reviewers for these 3 PostgreSQL related packages: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229321 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229322 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229323 > > Still looking for reviewers... Also I submitted another one yesterday. > This is ODBCng package for PostgreSQL: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235929 > Try exchanging reviews, look for a package you find interesting that needs a review and offer to review it in exchange for the submitter reviewing one of yours. This works for me every time. Regards, Hans From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 11 09:33:59 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 11 Apr 2007 11:33:59 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176244769.18654.18.camel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244185.2976.1.camel@localhost.localdomain> <1176244769.18654.18.camel@rousalka.dyndns.org> Message-ID: <20070411113359.3b16c3e6@python3.es.egwn.lan> Nicolas Mailhot wrote : > Le mercredi 11 avril 2007 ? 00:29 +0200, Matthias Clasen a ?crit : > > > US-ASCII is a meaningless term. There simply is no 8-bit ASCII > > Sure but ASCII is frequently abused nevertheless. And human lazyness > will "help" people choose the abusive interpretation. How about referring to "plain ASCII" in the guideline? 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 : 2.30 2.18 1.96 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 11 09:40:31 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 11 Apr 2007 11:40:31 +0200 Subject: FYI - cvs-import.sh changes In-Reply-To: <20070410191801.530daf8a@ludwig-alpha.unil.ch> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> Message-ID: <20070411114031.1279dbb3@python3.es.egwn.lan> Christian Iseli wrote : > It was noticed that the cvs-import script gets used by many folks, not > only for actually importing a new package into CVS, but also for > importing new versions of an existing package. > > This latter usage led to a few cases where changes made in CVS got > silently lost when the updated package was imported. > > After some discussions (like disallowing the use of cvs-import > for anything else than initial import) it was decided to modify the > script to at least show a diff of what's currently in CVS with what's > going to be imported (so that there is a chance the maintainer will > notice changes about to be undone), and will ask the maintainer to > enter a commit message. > > Thanks to Jens Petersen for implementing the changes. This is definitely a good thing. FWIW, I'm not even using that script anymore : Now that the CVS branches need to be "manually" created by the CVS admins, I simply do a "cvs update -d new-package-name" and then copy all of my local files (spec, patches, sources) to the new directory's devel sub-directory, use "make new-sources FILES="foo1 foo2" there, test a local build, then add/commit/tag and finally build :-) All this to say that cvs-import.sh isn't even actually _required_ anymore :-) 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 : 2.34 2.20 2.00 From mclasen at redhat.com Wed Apr 11 09:42:09 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 11 Apr 2007 11:42:09 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> Message-ID: <1176284529.2970.2.camel@localhost.localdomain> On Wed, 2007-04-11 at 09:48 +0200, Nicolas Mailhot wrote: > > We could define it as a negative "(ASCII does not include accented > > letters or special symbols like ?)". > > Been there, tried that, anything but a chart or an image like the one you > proposed is not a sufficient cluestick > > > Basically, I think a good portion of anglo-centric packagers won't know > > what the relationship is between ASCII and UTF-8. > > Sure. But a good portion of anglo-centric packagers won't know what ASCII > is either. Try to poll people someday you'll be surprised. > I think trying to make the packaging guidelines explain everything to the level that a random person on the street can understand is a loosing proposition. We can assume that packagers have more interest in these topics than the average computer user. Also we have a review process where any misunderstandings can be clarified in discussion with the reviewer. From jwboyer at jdub.homelinux.org Wed Apr 11 10:47:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Apr 2007 05:47:57 -0500 Subject: FYI - cvs-import.sh changes In-Reply-To: <20070411114031.1279dbb3@python3.es.egwn.lan> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <20070411114031.1279dbb3@python3.es.egwn.lan> Message-ID: <1176288477.4506.9.camel@vader.jdub.homelinux.org> On Wed, 2007-04-11 at 11:40 +0200, Matthias Saou wrote: > Christian Iseli wrote : > > > It was noticed that the cvs-import script gets used by many folks, not > > only for actually importing a new package into CVS, but also for > > importing new versions of an existing package. > > > > This latter usage led to a few cases where changes made in CVS got > > silently lost when the updated package was imported. > > > > After some discussions (like disallowing the use of cvs-import > > for anything else than initial import) it was decided to modify the > > script to at least show a diff of what's currently in CVS with what's > > going to be imported (so that there is a chance the maintainer will > > notice changes about to be undone), and will ask the maintainer to > > enter a commit message. > > > > Thanks to Jens Petersen for implementing the changes. > > This is definitely a good thing. > > FWIW, I'm not even using that script anymore : Now that the CVS > branches need to be "manually" created by the CVS admins, I simply do a "manually"? Why the quotes? I can assure you it's definitely a manual process. :) josh From Axel.Thimm at ATrpms.net Wed Apr 11 11:35:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 13:35:27 +0200 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt Message-ID: <20070411113527.GE11448@neu.nirvana> This is the report on the outcome of the EPEL votings to date. The one that passed needs a ratification by fesco (details are on http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): 1) Rebuild of EPEL5 Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan is to rebuild them against RHEL5. The question is: how? Winning option: Simply delete the current repo and rebuild all packages 2) Introduction of a repotag Topic: Should EPEL carry a repotag? If yes, the technical details will be delegated to the Packaging Committee. Vote turned down 3) Vetoing fedora-usermgmt until FPC makes a decision Topic: Packages should not use fedora-usermgmt or other non-standard useradd replacements. Vote turned down fesco needs to ratify the outcome of vote 1) above, the turned down votes don't need any ratification of course. -- 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 jwboyer at jdub.homelinux.org Wed Apr 11 11:59:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Apr 2007 06:59:16 -0500 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt In-Reply-To: <20070411113527.GE11448@neu.nirvana> References: <20070411113527.GE11448@neu.nirvana> Message-ID: <1176292756.6379.2.camel@zod.rchland.ibm.com> On Wed, 2007-04-11 at 13:35 +0200, Axel Thimm wrote: > This is the report on the outcome of the EPEL votings to date. The > one that passed needs a ratification by fesco (details are on > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): > > 1) Rebuild of EPEL5 > > Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan > is to rebuild them against RHEL5. The question is: how? > > Winning option: Simply delete the current repo and rebuild all packages Why can't you just bump the release for the packages and rebuild against a new buildroot? /me is confused by "delete the current repo". josh From dennis at ausil.us Wed Apr 11 12:02:47 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 11 Apr 2007 07:02:47 -0500 Subject: yum-3.0.5 bug - [Was : Mock builds borked for libgl} In-Reply-To: <1176253288.32458.75.camel@cutter> References: <461C3019.6050308@kobold.org> <1176253288.32458.75.camel@cutter> Message-ID: <200704110702.48032.dennis@ausil.us> Once upon a time Tuesday 10 April 2007, seth vidal wrote: > On Tue, 2007-04-10 at 17:47 -0700, Michael Thomas wrote: > > Seth wrote: > > > On Sat, 2007-04-07 at 15:15 +0200, Remi Collet wrote: > > > > Remi Collet a ?crit : > > > > > Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from > > > > core. > > > > > > Revert back to yum-3.0.3 solves the issue. > > > > > > Take a look in updates-testing at yum-3.0.5-2.fc6 - I think it solves > > > this one. > > > > > > thanks, > > > -sv > > > > Is this fix going to be pushed to the Fedora builders? I'm currently > > hitting the same libgl problem that Chris originally reported: > > > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/31361-compat-guich > >an05-0.5.0-4.fc6/x86_64/root.log > > the package is updates-testing and should go out to updates before long > - but ask the buildsystem keepers. all the builders are running yum-3.0.5-2.fc6 and have been for a couple of days. this version on yum was pushed on monday but does not fix the bug it seems. Dennis -------------- 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 Wed Apr 11 12:13:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 14:13:56 +0200 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt In-Reply-To: <1176292756.6379.2.camel@zod.rchland.ibm.com> References: <20070411113527.GE11448@neu.nirvana> <1176292756.6379.2.camel@zod.rchland.ibm.com> Message-ID: <20070411121356.GA18875@neu.nirvana> On Wed, Apr 11, 2007 at 06:59:16AM -0500, Josh Boyer wrote: > On Wed, 2007-04-11 at 13:35 +0200, Axel Thimm wrote: > > This is the report on the outcome of the EPEL votings to date. The > > one that passed needs a ratification by fesco (details are on > > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): > > > > 1) Rebuild of EPEL5 > > > > Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan > > is to rebuild them against RHEL5. The question is: how? > > > > Winning option: Simply delete the current repo and rebuild all packages > > Why can't you just bump the release for the packages and rebuild against > a new buildroot? > > /me is confused by "delete the current repo". There is a discussion thread (or more than one) on the epel-devel list and the key points are presented on the URL given 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 Axel.Thimm at ATrpms.net Wed Apr 11 12:16:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 14:16:49 +0200 Subject: FYI - cvs-import.sh changes In-Reply-To: <20070411114031.1279dbb3@python3.es.egwn.lan> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <20070411114031.1279dbb3@python3.es.egwn.lan> Message-ID: <20070411121649.GB18875@neu.nirvana> On Wed, Apr 11, 2007 at 11:40:31AM +0200, Matthias Saou wrote: > Christian Iseli wrote : > > > It was noticed that the cvs-import script gets used by many folks, not > > only for actually importing a new package into CVS, but also for > > importing new versions of an existing package. > > > > This latter usage led to a few cases where changes made in CVS got > > silently lost when the updated package was imported. > > > > After some discussions (like disallowing the use of cvs-import > > for anything else than initial import) it was decided to modify the > > script to at least show a diff of what's currently in CVS with what's > > going to be imported (so that there is a chance the maintainer will > > notice changes about to be undone), and will ask the maintainer to > > enter a commit message. > > > > Thanks to Jens Petersen for implementing the changes. > > This is definitely a good thing. > > FWIW, I'm not even using that script anymore : Now that the CVS > branches need to be "manually" created by the CVS admins, I simply do a > "cvs update -d new-package-name" and then copy all of my local files > (spec, patches, sources) to the new directory's devel sub-directory, > use "make new-sources FILES="foo1 foo2" there, test a local build, then > add/commit/tag and finally build :-) > > All this to say that cvs-import.sh isn't even actually _required_ > anymore :-) In fact I thought that "not required" meant "not allowed" anymore, since only the CVS admins should import packages until a new mechanism is put in place. Did some packagers cheat? :) -- 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 jwboyer at jdub.homelinux.org Wed Apr 11 12:20:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Apr 2007 07:20:00 -0500 Subject: Outcome of first EPEL votes: Rebuild, Repotag and fedora-usermgmt In-Reply-To: <20070411121356.GA18875@neu.nirvana> References: <20070411113527.GE11448@neu.nirvana> <1176292756.6379.2.camel@zod.rchland.ibm.com> <20070411121356.GA18875@neu.nirvana> Message-ID: <1176294000.6379.8.camel@zod.rchland.ibm.com> On Wed, 2007-04-11 at 14:13 +0200, Axel Thimm wrote: > On Wed, Apr 11, 2007 at 06:59:16AM -0500, Josh Boyer wrote: > > On Wed, 2007-04-11 at 13:35 +0200, Axel Thimm wrote: > > > This is the report on the outcome of the EPEL votings to date. The > > > one that passed needs a ratification by fesco (details are on > > > http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting): > > > > > > 1) Rebuild of EPEL5 > > > > > > Topic: The packages currently in EPEL5 got build against RHEL5beta1; the plan > > > is to rebuild them against RHEL5. The question is: how? > > > > > > Winning option: Simply delete the current repo and rebuild all packages > > > > Why can't you just bump the release for the packages and rebuild against > > a new buildroot? > > > > /me is confused by "delete the current repo". > > There is a discussion thread (or more than one) on the epel-devel list > and the key points are presented on the URL given above. fedoraproject.org is down at the moment. I'll read it when it's back up. josh From jwboyer at jdub.homelinux.org Wed Apr 11 12:21:21 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 11 Apr 2007 07:21:21 -0500 Subject: FYI - cvs-import.sh changes In-Reply-To: <20070411121649.GB18875@neu.nirvana> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <20070411114031.1279dbb3@python3.es.egwn.lan> <20070411121649.GB18875@neu.nirvana> Message-ID: <1176294081.6379.10.camel@zod.rchland.ibm.com> On Wed, 2007-04-11 at 14:16 +0200, Axel Thimm wrote: > On Wed, Apr 11, 2007 at 11:40:31AM +0200, Matthias Saou wrote: > > Christian Iseli wrote : > > > > > It was noticed that the cvs-import script gets used by many folks, not > > > only for actually importing a new package into CVS, but also for > > > importing new versions of an existing package. > > > > > > This latter usage led to a few cases where changes made in CVS got > > > silently lost when the updated package was imported. > > > > > > After some discussions (like disallowing the use of cvs-import > > > for anything else than initial import) it was decided to modify the > > > script to at least show a diff of what's currently in CVS with what's > > > going to be imported (so that there is a chance the maintainer will > > > notice changes about to be undone), and will ask the maintainer to > > > enter a commit message. > > > > > > Thanks to Jens Petersen for implementing the changes. > > > > This is definitely a good thing. > > > > FWIW, I'm not even using that script anymore : Now that the CVS > > branches need to be "manually" created by the CVS admins, I simply do a > > "cvs update -d new-package-name" and then copy all of my local files > > (spec, patches, sources) to the new directory's devel sub-directory, > > use "make new-sources FILES="foo1 foo2" there, test a local build, then > > add/commit/tag and finally build :-) > > > > All this to say that cvs-import.sh isn't even actually _required_ > > anymore :-) > > In fact I thought that "not required" meant "not allowed" anymore, > since only the CVS admins should import packages until a new mechanism > is put in place. Did some packagers cheat? :) No, that's incorrect. CVS admins don't do the package imports. They create the modules and branch directories, but that's all. Package importing is still done by the packagers. josh From Axel.Thimm at ATrpms.net Wed Apr 11 12:31:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 14:31:15 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <461BEFCD.3090900@fedoraproject.org> References: <4618E08B.9020300@fedoraproject.org> <461BEFCD.3090900@fedoraproject.org> Message-ID: <20070411123115.GC18875@neu.nirvana> On Wed, Apr 11, 2007 at 01:43:01AM +0530, Rahul Sundaram wrote: > Panu Matilainen wrote: > >On Sun, 8 Apr 2007, Rahul Sundaram wrote: > > > >>Hi > >> > >>The current thinking seems to be to just ignore them* but this is > >>guaranteed to result in a lot of confusion. When end users do a > >>distribution upgrade via yum or Anaconda, some of the packages might > >>not have been updated to the Fedora 7 version due to incorrect > >>packaging or other issues while the rest are packages which are > >>deliberated not rebuild to avoid churn. Debugging a end user system > >>with such a mix of packages is very painful. > > > >Dist tags considered harmful... :) RHEL 5 suffers from this same > >syndrome, it has loads of packages tagged "fc6" which I could imagine > >causing quite a bit of confusion as well. > > Since you ask, this is one of the main reasons I said it is guaranteed > to cause confusion. If anybody can calculate the amount of money Red Hat > loses in having support people attend to such issues I would doubt they > would consider it merely a cosmetic issue anymore. consider the amount of money spent on developer time when a one-liner security fix applied to an old never-rebuilt package makes it boom at run-time. And forget about RH's money, since some people yell, that this is not RHEL we're talking about - the same applies to F7: Nobody guarantees that a rebuild of foo-1.2.3-4.fc6 on F7 would give you a working package. For example bridge-utils was built under FC6 against a 2.6.18 kernel. If it uses ioctls or any /proc interface that has been deprecated in 2.6.19 and will be obsoleted in 2.6.21, then it will explode w/o a warning during F7 maintenance time. While a rebuild now would have a chance to spitt some deprecated warnings onto the sceen on usage. The above example is constructed, while bridge-utils is indeed built at the _beginning_ of FC6 and indeed has a BR of kernel-headers, e.g. a completely different build environment than it would have today in F7, whether the kernel API changed in the bridging area would have to be checked, most likely nothing happens. But there are quite a few other packages that were built against ancient kernel-headers, and glibc form FC6 to F7 also has some changes that may or may not break things, especially some kernel 2.4 interfaces upgraded to 2.6, so any software that was built against these interfaces may simply break at runtime (I think it was sys/personality, but anyone who cares should really simply diff FC6 and F7 glibc include files to get an idea of the differences of 2.5 vs 2.5.90). The fc6 tag is really cosmetics in comparison to what we may run into w/o a proper rebuild. In fact we should really keep them (the tags), so when a package explodes the user/bug reporter/bug assignee will be able to identify the distribution the package was built on and perhaps derive that that's the real issue. So my recommendation on the subject is: a) always do a full rebuild at a specific point in the release cycle (until now FC did rebuilds of 95-100% and FE of 100%) b) If the above is not wanted, then keep the disttags as is so that the "age" of the package or, better said, its the build environment can be estimated. You can find more examples and background, as well as rebuild statistics on the fedora-packaging list, but please keep the discussion here. -- 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 Wed Apr 11 12:33:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 14:33:14 +0200 Subject: FYI - cvs-import.sh changes In-Reply-To: <1176294081.6379.10.camel@zod.rchland.ibm.com> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <20070411114031.1279dbb3@python3.es.egwn.lan> <20070411121649.GB18875@neu.nirvana> <1176294081.6379.10.camel@zod.rchland.ibm.com> Message-ID: <20070411123314.GD18875@neu.nirvana> On Wed, Apr 11, 2007 at 07:21:21AM -0500, Josh Boyer wrote: > On Wed, 2007-04-11 at 14:16 +0200, Axel Thimm wrote: > > On Wed, Apr 11, 2007 at 11:40:31AM +0200, Matthias Saou wrote: > > > Christian Iseli wrote : > > > > > > > It was noticed that the cvs-import script gets used by many folks, not > > > > only for actually importing a new package into CVS, but also for > > > > importing new versions of an existing package. > > > All this to say that cvs-import.sh isn't even actually _required_ > > > anymore :-) > > > > In fact I thought that "not required" meant "not allowed" anymore, > > since only the CVS admins should import packages until a new mechanism > > is put in place. Did some packagers cheat? :) > > No, that's incorrect. CVS admins don't do the package imports. They > create the modules and branch directories, but that's all. Package > importing is still done by the packagers. Ah, OK, thanks for clarifying! :) -- 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 nicolas.mailhot at laposte.net Wed Apr 11 13:01:20 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 15:01:20 +0200 (CEST) Subject: FYI - cvs-import.sh changes In-Reply-To: <20070411121649.GB18875@neu.nirvana> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <20070411114031.1279dbb3@python3.es.egwn.lan> <20070411121649.GB18875@neu.nirvana> Message-ID: <58677.192.54.193.51.1176296480.squirrel@rousalka.dyndns.org> Le Mer 11 avril 2007 14:16, Axel Thimm a ?crit : >> All this to say that cvs-import.sh isn't even actually _required_ >> anymore :-) > > In fact I thought that "not required" meant "not allowed" anymore, > since only the CVS admins should import packages until a new mechanism > is put in place. Did some packagers cheat? :) Some people like me use cvs-import.sh to upload new versions in a controlled manner : 1. cvs co + make srpm to get the current package state 2. expand the srpm in a clean root, modify it 3. rpmbuild -bs --nodeps 4. mock the result 5. test 6. cvs-import the mock-produced srpm changeset And yes that's not how everyone works but not having to interact directly with cvs (appart from the initial co) keeps me semi-sane. -- Nicolas Mailhot From jkeating at redhat.com Wed Apr 11 13:04:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 09:04:59 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070411123115.GC18875@neu.nirvana> References: <4618E08B.9020300@fedoraproject.org> <461BEFCD.3090900@fedoraproject.org> <20070411123115.GC18875@neu.nirvana> Message-ID: <200704110905.00183.jkeating@redhat.com> On Wednesday 11 April 2007 08:31:15 Axel Thimm wrote: > The fc6 tag is really cosmetics in comparison to what we may run into > w/o a proper rebuild. In fact we should really keep them (the tags), > so when a package explodes the user/bug reporter/bug assignee will be > able to identify the distribution the package was built on and perhaps > derive that that's the real issue. With Koji, it is pretty easy to find out EXACTLY what packages were in the buildroot to build any given package. The dist tag is not necessary for guessing. All your above scenarios are valid, and can be mitigated by on the side continuous rebuilds of packages to identify when changes might happen, which would allow the maintainers and release team to make decisions as to which packages should be rebuilt for a new build chain. It does not mean we should just blanket rebuild everything just because we can and there could POTENTIALLY be issues in SOME packages. -- 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 Wed Apr 11 13:06:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 09:06:53 -0400 Subject: FYI - cvs-import.sh changes In-Reply-To: <20070411123314.GD18875@neu.nirvana> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <1176294081.6379.10.camel@zod.rchland.ibm.com> <20070411123314.GD18875@neu.nirvana> Message-ID: <200704110906.53650.jkeating@redhat.com> On Wednesday 11 April 2007 08:33:14 Axel Thimm wrote: > > No, that's incorrect. ?CVS admins don't do the package imports. ?They > > create the modules and branch directories, but that's all. ?Package > > importing is still done by the packagers. > > Ah, OK, thanks for clarifying! :) Also, cvs-import.sh can be used to import new srpms into existing modules. I find this quite handy when I do a new upstream srpm release of pungi, and I know that no commits were done to my pungi Extras module since the last release. Now that cvs-import.sh gives me a diff and the ability to add a log message this is made even easier/better. I can bail if something DID change and my import would overwrite it. Use of cvs-import.sh makes my workflow very smooth. -- 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 Wed Apr 11 13:11:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 15:11:04 +0200 Subject: FYI - cvs-import.sh changes In-Reply-To: <58677.192.54.193.51.1176296480.squirrel@rousalka.dyndns.org> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <20070411114031.1279dbb3@python3.es.egwn.lan> <20070411121649.GB18875@neu.nirvana> <58677.192.54.193.51.1176296480.squirrel@rousalka.dyndns.org> Message-ID: <20070411131104.GF18875@neu.nirvana> On Wed, Apr 11, 2007 at 03:01:20PM +0200, Nicolas Mailhot wrote: > > Le Mer 11 avril 2007 14:16, Axel Thimm a ?crit : > > >> All this to say that cvs-import.sh isn't even actually _required_ > >> anymore :-) > > > > In fact I thought that "not required" meant "not allowed" anymore, > > since only the CVS admins should import packages until a new mechanism > > is put in place. Did some packagers cheat? :) > > Some people like me use cvs-import.sh to upload new versions in a > controlled manner : > > 1. cvs co + make srpm to get the current package state > 2. expand the srpm in a clean root, modify it > 3. rpmbuild -bs --nodeps > 4. mock the result > 5. test > 6. cvs-import the mock-produced srpm changeset > > And yes that's not how everyone works but not having to interact directly > with cvs (appart from the initial co) keeps me semi-sane. I think it makes very much sense to hide as much of the underlying VCS as possible, since we do want to replace CVS with something else. Maybe we should work more toward a VCS-neutral way of workflow. -- 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 Wed Apr 11 13:14:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 09:14:50 -0400 Subject: FYI - cvs-import.sh changes In-Reply-To: <20070411131104.GF18875@neu.nirvana> References: <20070410191801.530daf8a@ludwig-alpha.unil.ch> <58677.192.54.193.51.1176296480.squirrel@rousalka.dyndns.org> <20070411131104.GF18875@neu.nirvana> Message-ID: <200704110914.51155.jkeating@redhat.com> On Wednesday 11 April 2007 09:11:04 Axel Thimm wrote: > Maybe we should work more toward a VCS-neutral way of workflow. Yes please. I'm not intersted in just switching SCMs. I'm interested in improving / enhancing the workflow, taking that desired workflow and finding an SCM that suits it, or can be confirmed to suit it. I want to work from the idea of a workflow rather than an idea of "here is this whizbang scm, we could do things _this_ way with this scm". -- 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 Wed Apr 11 13:20:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 15:20:37 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <200704110905.00183.jkeating@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <461BEFCD.3090900@fedoraproject.org> <20070411123115.GC18875@neu.nirvana> <200704110905.00183.jkeating@redhat.com> Message-ID: <20070411132037.GG18875@neu.nirvana> On Wed, Apr 11, 2007 at 09:04:59AM -0400, Jesse Keating wrote: > On Wednesday 11 April 2007 08:31:15 Axel Thimm wrote: > > The fc6 tag is really cosmetics in comparison to what we may run into > > w/o a proper rebuild. In fact we should really keep them (the tags), > > so when a package explodes the user/bug reporter/bug assignee will be > > able to identify the distribution the package was built on and perhaps > > derive that that's the real issue. > > With Koji, it is pretty easy to find out EXACTLY what packages were in the > buildroot to build any given package. The dist tag is not necessary for > guessing. We did have buildlogs with plague, too. I don't know how long they were kept, though, and certainly no user/reporter ever cared to look into them. > All your above scenarios are valid, and can be mitigated by on the side > continuous rebuilds of packages to identify when changes might happen, which > would allow the maintainers and release team to make decisions as to which > packages should be rebuilt for a new build chain. You only test whether it builds, not whether it runs. To continue the bridge-utils example: If it is busted and only shows that it is once you try to setup STP on the bridge, who will teh continuous rebuild show you that? You can only do that by either investing in-house QA for every package update you are going to ship (and we know that these are going to be a loadful per week), or do so in advance during the development/testing cycle. It's just a matter of when it will happen, not if and how much resources it will consume. And I think having it happen during F7testX is better than during F7 package maintenance, or even worse, if it slips the package updating QA and makes it into the proper released updates. Because I doubt that a one-line fix in the ever abused bridge-utils example will make the packager that fixed it to test all aspects of Linux bridging again. > It does not mean we should just blanket rebuild everything just > because we can and there could POTENTIALLY be issues in SOME > packages. If the issues are only potentially, why are you afraid of rebuilding? The arguments were a) too much download volume and b) stable packages. The first argument is void, since the big players consuming 99% of the bandwidth have been rebuilt (for the record, w/o weighing by size FC6 had 80% rebuilt, and the big players were among them). The second argument on stability is also void, since either the package is stable and survives a rebuild, or it is as fragile to not do so. And in that case, we'd like to know before the release, that the package is in a fubar state of affairs. You don't save anything, you just push the problem from the development cycle into the maintenance cycle. -- 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 ssorce at redhat.com Wed Apr 11 13:59:05 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 11 Apr 2007 09:59:05 -0400 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> Message-ID: <1176299945.26832.55.camel@willson> On Wed, 2007-04-11 at 09:48 +0200, Nicolas Mailhot wrote: > This will be fine > http://en.wikipedia.org/wiki/ASCII#ASCII_printable_characters > may work too (although the text before the table may be confusing) > > > We could define it as a negative "(ASCII does not include accented > > letters or special symbols like ?)". > > Been there, tried that, anything but a chart or an image like the one you > proposed is not a sufficient cluestick Guys, just "man ascii", is all you need, simple and available on all systems. with a table, concise text and no we references that can change. >From the man page: ASCII is the American Standard Code for Information Interchange. It is a 7-bit code. Many 8-bit codes (such as ISO 8859-1, the Linux default character set) contain ASCII as their lower half. The international counterpart of ASCII is known as ISO 646. We could also say something like: The following characters are ok for use in any file name: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ But the fisrt form is the easiest one, reading a man page is pretty straight forward. > > Basically, I think a good portion of anglo-centric packagers won't know > > what the relationship is between ASCII and UTF-8. > > Sure. But a good portion of anglo-centric packagers won't know what ASCII > is either. Try to poll people someday you'll be surprised. > > Regards, > From ssorce at redhat.com Wed Apr 11 14:04:16 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 11 Apr 2007 10:04:16 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070411132037.GG18875@neu.nirvana> References: <4618E08B.9020300@fedoraproject.org> <461BEFCD.3090900@fedoraproject.org> <20070411123115.GC18875@neu.nirvana> <200704110905.00183.jkeating@redhat.com> <20070411132037.GG18875@neu.nirvana> Message-ID: <1176300256.26832.57.camel@willson> On Wed, 2007-04-11 at 15:20 +0200, Axel Thimm wrote: > On Wed, Apr 11, 2007 at 09:04:59AM -0400, Jesse Keating wrote: > > On Wednesday 11 April 2007 08:31:15 Axel Thimm wrote: > > > The fc6 tag is really cosmetics in comparison to what we may run into > > > w/o a proper rebuild. In fact we should really keep them (the tags), > > > so when a package explodes the user/bug reporter/bug assignee will be > > > able to identify the distribution the package was built on and perhaps > > > derive that that's the real issue. > > > > With Koji, it is pretty easy to find out EXACTLY what packages were in the > > buildroot to build any given package. The dist tag is not necessary for > > guessing. > > We did have buildlogs with plague, too. I don't know how long they > were kept, though, and certainly no user/reporter ever cared to look > into them. > > > All your above scenarios are valid, and can be mitigated by on the side > > continuous rebuilds of packages to identify when changes might happen, which > > would allow the maintainers and release team to make decisions as to which > > packages should be rebuilt for a new build chain. > > You only test whether it builds, not whether it runs. To continue the > bridge-utils example: If it is busted and only shows that it is once > you try to setup STP on the bridge, who will teh continuous rebuild > show you that? You can only do that by either investing in-house QA > for every package update you are going to ship (and we know that these > are going to be a loadful per week), or do so in advance during the > development/testing cycle. > > It's just a matter of when it will happen, not if and how much > resources it will consume. And I think having it happen during F7testX > is better than during F7 package maintenance, or even worse, if it > slips the package updating QA and makes it into the proper released > updates. Because I doubt that a one-line fix in the ever abused > bridge-utils example will make the packager that fixed it to test all > aspects of Linux bridging again. > > > It does not mean we should just blanket rebuild everything just > > because we can and there could POTENTIALLY be issues in SOME > > packages. > > If the issues are only potentially, why are you afraid of rebuilding? > The arguments were a) too much download volume and b) stable > packages. > > The first argument is void, since the big players consuming 99% of the > bandwidth have been rebuilt (for the record, w/o weighing by size FC6 > had 80% rebuilt, and the big players were among them). > > The second argument on stability is also void, since either the > package is stable and survives a rebuild, or it is as fragile to not > do so. And in that case, we'd like to know before the release, that > the package is in a fubar state of affairs. > > You don't save anything, you just push the problem from the development > cycle into the maintenance cycle. +1 your arguments are rock solid imo! Simo. From buildsys at fedoraproject.org Wed Apr 11 14:11:00 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 11 Apr 2007 10:11:00 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-11 Message-ID: <20070411141100.2C794152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) miker5slow AT grandecom.net: etherape FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) mr.ecik AT gmail.com: kadu FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) qspencer AT ieee.org: lilypond FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- etherape: miker5slow AT grandecom.net FE5 > FE6 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc6) FE5 > FE7 (0:0.9.7-4.1.fc5 > 0:0.9.7-4.fc7) flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) kadu: mr.ecik AT gmail.com FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) lilypond: qspencer AT ieee.org FE5 > FE6 (0:2.10.17-2.fc5 > 0:2.10.17-1.fc6) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.6-2.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.6-2.fc6 > 0:2.9.4-2.fc6) From jkeating at redhat.com Wed Apr 11 14:36:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 10:36:23 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070411132037.GG18875@neu.nirvana> References: <4618E08B.9020300@fedoraproject.org> <200704110905.00183.jkeating@redhat.com> <20070411132037.GG18875@neu.nirvana> Message-ID: <200704111036.23800.jkeating@redhat.com> On Wednesday 11 April 2007 09:20:37 Axel Thimm wrote: > You only test whether it builds, not whether it runs. To continue the > bridge-utils example: If it is busted and only shows that it is once > you try to setup STP on the bridge, who will teh continuous rebuild > show you that? You can only do that by either investing in-house QA > for every package update you are going to ship (and we know that these > are going to be a loadful per week), or do so in advance during the > development/testing cycle. No, I said the continuous rebuild pared with automated testing of what falls out of that. The same automated testing that could be applied to any other build of a package. This is a much broader need. -- 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 Wed Apr 11 15:14:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 17:14:19 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <200704111036.23800.jkeating@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <200704110905.00183.jkeating@redhat.com> <20070411132037.GG18875@neu.nirvana> <200704111036.23800.jkeating@redhat.com> Message-ID: <20070411151419.GJ18875@neu.nirvana> On Wed, Apr 11, 2007 at 10:36:23AM -0400, Jesse Keating wrote: > On Wednesday 11 April 2007 09:20:37 Axel Thimm wrote: > > You only test whether it builds, not whether it runs. To continue the > > bridge-utils example: If it is busted and only shows that it is once > > you try to setup STP on the bridge, who will teh continuous rebuild > > show you that? You can only do that by either investing in-house QA > > for every package update you are going to ship (and we know that these > > are going to be a loadful per week), or do so in advance during the > > development/testing cycle. > > No, I said the continuous rebuild pared with automated testing of what falls > out of that. The same automated testing that could be applied to any other > build of a package. This is a much broader need. Whatever testing can be automated belongs to %check or similar. The real-life testing can't be automated, and makes the real difference. Even for the bridge-util example above the run time test units would involve several pieces of real hardware to be tested on. And no, xen bridges don't count, because they are broken. That's why you want this to be in rawhide and not in some optional-whoever-is-kind-enough-should-please-use-this-repo-of-rebuilds. Some people argue that it will make a difference to harbor Matt's rebuilds under the fp.o umbrella, e.g. bless them with a Fedora stick. I really doubt that a change of domain name and other marketing gags would bring the testing body required. We only have a limited amount of testers, and two rawhides are one too much. -- 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 Wed Apr 11 15:19:15 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 11 Apr 2007 18:19:15 +0300 Subject: yum-3.0.5 bug - [Was : Mock builds borked for libgl} In-Reply-To: <200704110702.48032.dennis@ausil.us> References: <461C3019.6050308@kobold.org> <1176253288.32458.75.camel@cutter> <200704110702.48032.dennis@ausil.us> Message-ID: <200704111819.15686.ville.skytta@iki.fi> On Wednesday 11 April 2007, Dennis Gilmore wrote: > Once upon a time Tuesday 10 April 2007, seth vidal wrote: > > > > the package is updates-testing and should go out to updates before long > > - but ask the buildsystem keepers. > > all the builders are running yum-3.0.5-2.fc6 and have been for a couple of > days. this version on yum was pushed on monday but does not fix the bug it > seems. That was a different bug, I think Seth is referring to 3.0.6-1 in updates-testing for this particular fix. From wart at kobold.org Wed Apr 11 15:35:57 2007 From: wart at kobold.org (Wart) Date: Wed, 11 Apr 2007 08:35:57 -0700 Subject: yum-3.0.5 bug - [Was : Mock builds borked for libgl} In-Reply-To: <200704110702.48032.dennis@ausil.us> References: <461C3019.6050308@kobold.org> <1176253288.32458.75.camel@cutter> <200704110702.48032.dennis@ausil.us> Message-ID: <461D005D.1010100@kobold.org> Dennis Gilmore wrote: > Once upon a time Tuesday 10 April 2007, seth vidal wrote: >> On Tue, 2007-04-10 at 17:47 -0700, Michael Thomas wrote: >>> Seth wrote: >>> > On Sat, 2007-04-07 at 15:15 +0200, Remi Collet wrote: >>> > > Remi Collet a ?crit : >>> > > > Yum choose glib2-2.12.9 from updates and glib2-devel-2.12.3 from >>> >>> core. >>> >>> > > Revert back to yum-3.0.3 solves the issue. >>> > >>> > Take a look in updates-testing at yum-3.0.5-2.fc6 - I think it solves >>> > this one. >>> > >>> > thanks, >>> > -sv >>> >>> Is this fix going to be pushed to the Fedora builders? I'm currently >>> hitting the same libgl problem that Chris originally reported: >>> >>> http://buildsys.fedoraproject.org/logs/fedora-6-extras/31361-compat-guich >>> an05-0.5.0-4.fc6/x86_64/root.log >> the package is updates-testing and should go out to updates before long >> - but ask the buildsystem keepers. > > all the builders are running yum-3.0.5-2.fc6 and have been for a couple of > days. this version on yum was pushed on monday but does not fix the bug it > seems. The build fairy must have fixed this and re-queued my builds overnight, because when I woke up this morning I found 'build success' messages under my pillow for both packages that had this problem yesterday. --Wart From nicolas.mailhot at laposte.net Wed Apr 11 15:44:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 17:44:32 +0200 (CEST) Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176299945.26832.55.camel@willson> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> <1176299945.26832.55.camel@willson> Message-ID: <21947.192.54.193.51.1176306272.squirrel@rousalka.dyndns.org> Le Mer 11 avril 2007 15:59, Simo Sorce a ?crit : > just "man ascii", is all you need, simple and available on all systems. > with a table, concise text and no we references that can change. That's not something we can easily reference in a wiki though -- Nicolas Mailhot From sundaram at fedoraproject.org Wed Apr 11 15:59:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 11 Apr 2007 21:29:36 +0530 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <21947.192.54.193.51.1176306272.squirrel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> <1176299945.26832.55.camel@willson> <21947.192.54.193.51.1176306272.squirrel@rousalka.dyndns.org> Message-ID: <461D05E8.2000307@fedoraproject.org> Nicolas Mailhot wrote: > Le Mer 11 avril 2007 15:59, Simo Sorce a ?crit : > >> just "man ascii", is all you need, simple and available on all systems. >> with a table, concise text and no we references that can change. > > That's not something we can easily reference in a wiki though We should be able to. My idea long back is now part of the Google SoC projects. http://fedoraproject.org/wiki/SummerOfCode/2007/RiaDas Rahul From mastahnke at gmail.com Wed Apr 11 16:01:15 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 11 Apr 2007 11:01:15 -0500 Subject: Looking for reviewers In-Reply-To: <461CA122.4030202@hhs.nl> References: <1174868341.4352.5.camel@laptop.gunduz.org> <1176273568.3055.7.camel@laptop.gunduz.org> <461CA122.4030202@hhs.nl> Message-ID: <7874d9dd0704110901m5d25d314r46bb22005fe15e6f@mail.gmail.com> A time this doesn't work is if the packager is new, and has no experience reviewing packages. Granted, learning to review is great, but someone with a little more experience should probably oversee the review. I know I stumbled through a few before I felt comfortable doing some completely on my own, and still refer to experts on many. However, this method certainly does have merit, and please don't give up on my account. I just know that when I was new to Fedora, that's how it worked for me. I also like to know something about the packages I review. I mean, I can rpmlint with the best of them, but since I don't run Postgres at all, reviewing these packages (to me at least) doesn't make a whole lot of sense. Maybe I wrong here though. I find that if I understand the package, or at least the related items, I can offer a better review; thus hopefully improving the entire Fedora experience. stahnma On 4/11/07, Hans de Goede wrote: > Devrim G?ND?Z wrote: > > Hi, > > > > On Mon, 2007-03-26 at 03:19 +0300, Devrim G?ND?Z wrote: > >> I'm looking for reviewers for these 3 PostgreSQL related packages: > >> > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229321 > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229322 > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229323 > > > > Still looking for reviewers... Also I submitted another one yesterday. > > This is ODBCng package for PostgreSQL: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235929 > > > > Try exchanging reviews, look for a package you find interesting that needs a > review and offer to review it in exchange for the submitter reviewing one of yours. > > This works for me every time. > > Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From limb at jcomserv.net Wed Apr 11 16:03:44 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 11 Apr 2007 11:03:44 -0500 (CDT) Subject: Looking for reviewers In-Reply-To: <7874d9dd0704110901m5d25d314r46bb22005fe15e6f@mail.gmail.com> References: <1174868341.4352.5.camel@laptop.gunduz.org> <1176273568.3055.7.camel@laptop.gunduz.org> <461CA122.4030202@hhs.nl> <7874d9dd0704110901m5d25d314r46bb22005fe15e6f@mail.gmail.com> Message-ID: <51672.65.192.24.190.1176307424.squirrel@mail.jcomserv.net> > A time this doesn't work is if the packager is new, and has no > experience reviewing packages. Granted, learning to review is great, > but someone with a little more experience should probably oversee the > review. I know I stumbled through a few before I felt comfortable > doing some completely on my own, and still refer to experts on many. > > However, this method certainly does have merit, and please don't give > up on my account. I just know that when I was new to Fedora, that's > how it worked for me. +1 > I also like to know something about the packages I review. I mean, I > can rpmlint with the best of them, but since I don't run Postgres at > all, reviewing these packages (to me at least) doesn't make a whole > lot of sense. Maybe I wrong here though. I find that if I understand > the package, or at least the related items, I can offer a better > review; thus hopefully improving the entire Fedora experience. I agree. On the whole, I don't review packages whose functionality is beyond my ability to verify. While I'm by no means a Postgres guru, I've adapted a few of my own apps to support it, and have a test server. Then again, what better way to expand one's horizons? Learn by doing, no? > stahnma > > > On 4/11/07, Hans de Goede wrote: >> Devrim G?ND?Z wrote: >> > Hi, >> > >> > On Mon, 2007-03-26 at 03:19 +0300, Devrim G?ND?Z wrote: >> >> I'm looking for reviewers for these 3 PostgreSQL related packages: >> >> >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229321 >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229322 >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229323 >> > >> > Still looking for reviewers... Also I submitted another one yesterday. >> > This is ODBCng package for PostgreSQL: >> > >> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235929 >> > >> >> Try exchanging reviews, look for a package you find interesting that >> needs a >> review and offer to review it in exchange for the submitter reviewing >> one of yours. >> >> This works for me every time. >> >> Regards, >> >> Hans >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From caillon at redhat.com Wed Apr 11 17:27:36 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 11 Apr 2007 13:27:36 -0400 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <20070411123115.GC18875@neu.nirvana> References: <4618E08B.9020300@fedoraproject.org> <461BEFCD.3090900@fedoraproject.org> <20070411123115.GC18875@neu.nirvana> Message-ID: <461D1A88.3000209@redhat.com> Axel Thimm wrote: > consider the amount of money spent on developer time when a one-liner > security fix applied to an old never-rebuilt package makes it boom at > run-time. The developer time is going to be spent at some point because it went boom at some point. Potentially it's less time if it went boom three times and the developer only has to fix it once if he waits. You're not saving money here, you're just shifting when it's spent. From mclasen at redhat.com Wed Apr 11 17:51:17 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 11 Apr 2007 19:51:17 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <21947.192.54.193.51.1176306272.squirrel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> <1176299945.26832.55.camel@willson> <21947.192.54.193.51.1176306272.squirrel@rousalka.dyndns.org> Message-ID: <1176313877.2993.3.camel@localhost.localdomain> On Wed, 2007-04-11 at 17:44 +0200, Nicolas Mailhot wrote: > Le Mer 11 avril 2007 15:59, Simo Sorce a ?crit : > > > just "man ascii", is all you need, simple and available on all systems. > > with a table, concise text and no we references that can change. > > That's not something we can easily reference in a wiki though > Sure you can. I sure hope our packagers don't belong to the if-I-can't-click-on-it-it-doesn't-exist camp... From Jerry.James at usu.edu Wed Apr 11 18:29:22 2007 From: Jerry.James at usu.edu (Jerry James) Date: Wed, 11 Apr 2007 12:29:22 -0600 Subject: Moodle: language packs and FC-4 Message-ID: I've just taken over maintenance of moodle. I'm planning to update the FC-5 and FC-6 branches to 1.6.5 to fix some security problems. I'm also going to update the devel branch to 1.8 for the same reason, and because we might as well get the latest version into devel. I need some advice on two questions I have. First, CVS has an FC-4 directory under moodle. Do I need to maintain that? I thought FC 4 had been end-of-lifed. As a general interest question, when a distribution is end-of-lifed, do package maintainers need to do anything special to dump the affected directories, or does some CVS administrator work magic to make them disappear eventually? Second, the current moodle RPM copies everything in the source directory install/lang to lang. This results in the language files being included in the main RPM twice, once in each place, and also in individual language RPMs. In addition to this goof, some previous packager misunderstood the purpose of those files. They are not supposed to be moved out of install/lang. They are language files for the installation process only, which we partially automate anyway. The language files for actual use are here: http://download.moodle.org/lang16/ The language file names do not change as they are updated. However, there is a date stamp on that web page for each language file, allowing us to keep track of which version is in a given RPM. I can see two ways of dealing with this situation, each with pros and cons. 1) Download all of the language files and include them in one monolithic moodle SRPM. Split out the installation and use files for each language into a language subpackage. This lets us keep all the files for a particular language in one place, but means that anytime an individual language file gets updated, we have to rebuild the whole thing. 2) Embrace the fact that the installation language files are small (a few hundred bytes to a few K apiece), and partially unnecessary anyway. Just put them into the main moodle package (once!). Create separate SRPMs for each language file with the date stamp for the version number. Now language packs can be updated individually, but this also means that I will suddenly be the maintainer for 60+ additional packages in which I have no personal interest. Any advice? Thanks, -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From nicolas.mailhot at laposte.net Wed Apr 11 18:17:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Apr 2007 20:17:35 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176313877.2993.3.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> <1176299945.26832.55.camel@willson> <21947.192.54.193.51.1176306272.squirrel@rousalka.dyndns.org> <1176313877.2993.3.camel@localhost.localdomain> Message-ID: <1176315455.16445.6.camel@rousalka.dyndns.org> Le mercredi 11 avril 2007 ? 19:51 +0200, Matthias Clasen a ?crit : > On Wed, 2007-04-11 at 17:44 +0200, Nicolas Mailhot wrote: > > Le Mer 11 avril 2007 15:59, Simo Sorce a ?crit : > > > > > just "man ascii", is all you need, simple and available on all systems. > > > with a table, concise text and no we references that can change. > > > > That's not something we can easily reference in a wiki though > Sure you can. I sure hope our packagers don't belong to the > if-I-can't-click-on-it-it-doesn't-exist camp... When you've been a technical writer you know readers, like water, follow the path of least resistance. You want people to follow guidelines you make clear and simple instructions, you don't waste time waiting for the mythical will-do subject. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Wed Apr 11 19:41:56 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 11 Apr 2007 22:41:56 +0300 Subject: Moodle: language packs and FC-4 In-Reply-To: References: Message-ID: <200704112241.57000.ville.skytta@iki.fi> On Wednesday 11 April 2007, Jerry James wrote: > First, CVS has an FC-4 directory under moodle. Do I need to maintain > that? No. I don't think it's forbidden either if you find it useful for some reason, but one can't build packages for FC-4 any more with the FE build system. > I thought FC 4 had been end-of-lifed. As a general interest > question, when a distribution is end-of-lifed, do package maintainers > need to do anything special to dump the affected directories, or does > some CVS administrator work magic to make them disappear eventually? Traditionally, they have been left hanging around indefinitely, and I think that's fine. From Axel.Thimm at ATrpms.net Wed Apr 11 20:17:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 11 Apr 2007 22:17:37 +0200 Subject: Packages with "fc6" name in Fedora 7 In-Reply-To: <461D1A88.3000209@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <461BEFCD.3090900@fedoraproject.org> <20070411123115.GC18875@neu.nirvana> <461D1A88.3000209@redhat.com> Message-ID: <20070411201737.GA30458@neu.nirvana> On Wed, Apr 11, 2007 at 01:27:36PM -0400, Christopher Aillon wrote: > Axel Thimm wrote: > >consider the amount of money spent on developer time when a one-liner > >security fix applied to an old never-rebuilt package makes it boom at > >run-time. > > The developer time is going to be spent at some point because it went > boom at some point. Potentially it's less time if it went boom three > times and the developer only has to fix it once if he waits. You're not > saving money here, you're just shifting when it's spent. Exactly, all I say (later in the mail) is that fixing the broken package is inevitable, you can choose between fixing it at development time, or during release maintenance time. And since the resources will have to be spend on this either way, why not during the development to deliver a better product? Furthermore *now* during development you have lots of guinea pigs that would go ahead and install the broken bridge-utils (if it really is, still using it as an example), and happily report on anything broken, even expecting something to be broken in a test release. Later the packager that will do the one-line fix will carry the whole responsibility of checking that bridge-utils really builds and works in a 2.6.2x environment all by himself or rush out a broken package update to production systems. In the non-rebuild model you have greater responsibility which even means spending "more money" for longer QA for a one-liner fix. And the results are still poorer than the rebuild-everything-and-see-what- breaks-at-runtime model. More gain for less or equal effort, so it already makes a business case. And you get a better product. -- 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 tibbs at math.uh.edu Wed Apr 11 22:16:23 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Apr 2007 17:16:23 -0500 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <20070411082949.GA3863@redhat.com> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> <20070411082949.GA3863@redhat.com> Message-ID: >>>>> "GB" == Gary Benson writes: GB> Whatever we say, why not back that up with a check in rpmbuild? rpmlint should be growing a test for this soon, if it isn't there already. - J< From bpepple at fedoraproject.org Thu Apr 12 00:41:02 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 11 Apr 2007 20:41:02 -0400 Subject: Plan for tomorrows (20070412) FESCO meeting Message-ID: <1176338462.5907.3.camel@lincoln> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- new sponsor nominations anyone? /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- renaming cvsextras group -- warren /topic FESCO-Meeting -- MISC -- Package Conflicts - https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00017.html /topic FESCO-Meeting -- MISC -- Extras 7 preparation /topic FESCO-Meeting -- EPEL /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 Thu Apr 12 00:43:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Apr 2007 20:43:42 -0400 Subject: Plan for tomorrows (20070412) FESCO meeting In-Reply-To: <1176338462.5907.3.camel@lincoln> References: <1176338462.5907.3.camel@lincoln> Message-ID: <200704112043.42363.jkeating@redhat.com> On Wednesday 11 April 2007 20:41:02 Brian Pepple wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). /topic FESCo-Meeting -- Infrastructure -- Switch to Koji for building Extras (devel?) -- f13 (Jesse Keating) -- 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 tibbs at math.uh.edu Thu Apr 12 01:34:07 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Apr 2007 20:34:07 -0500 Subject: Summary of the 2007-04-10 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging meeting which occurred on 2007.04.10 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070410 Executive summary: No modifications to the guidelines this week. Issues pending FESCO ratification: * A statement of the responsibilities of reviewers and packagers during the package review process accepted (6 yea, 0 nay): http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals * Guidelines on the use of the Conflicts: tag accepted (5 yea, 0 nay): http://fedoraproject.org/wiki/PackagingDrafts/Conflicts Note that there was some confusion over whether this had actually been submitted to FESCO in the past, so erring on the side of caution, we made minor modifications and updates to the draft and formally present it now. Misc business: * Meeting time now inconvenient for some now that Europe has switched to DST. Discussion continues on the mailing list. Please see the minutes and log for full information. - J< From tibbs at math.uh.edu Thu Apr 12 03:03:13 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Apr 2007 22:03:13 -0500 Subject: Moodle: language packs and FC-4 In-Reply-To: References: Message-ID: >>>>> "JJ" == Jerry James writes: JJ> First, CVS has an FC-4 directory under moodle. Do I need to JJ> maintain that? No, you don't, but you can if you like. For example, I still maintain denyhosts for FC3 because I happen to need it for something and it's simpler to build it out of the CVS tree. You can't, however, issue builds for anything older than FC5. JJ> 1) Download all of the language files and include them in one JJ> monolithic moodle SRPM. Split out the installation and use files JJ> for each language into a language subpackage. This lets us keep JJ> all the files for a particular language in one place, but means JJ> that anytime an individual language file gets updated, we have to JJ> rebuild the whole thing. That may not be much of a problem if the language files don't change much more often than the package itself. JJ> 2) Embrace the fact that the installation language files are small JJ> (a few hundred bytes to a few K apiece), and partially unnecessary JJ> anyway. Just put them into the main moodle package (once!). JJ> Create separate SRPMs for each language file with the date stamp JJ> for the version number. Now language packs can be updated JJ> individually, but this also means that I will suddenly be the JJ> maintainer for 60+ additional packages in which I have no personal JJ> interest. I'd expect the maintenance overhead of one of these to be low, but having to rev 60 of them at a time might be just plain annoying. I think the final decision rests with you; you need to determine how much time you can invest and how much process you're willing to put up with. Perhaps you can find someone willing to assist you in maintaining these? I suppose that if nobody is willing to do so, you could simply drop those languages in which you're not interested. - J< From jkeating at redhat.com Thu Apr 12 13:12:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 09:12:33 -0400 Subject: Using Koji for building Extras Message-ID: <200704120912.33809.jkeating@redhat.com> Since this topic will be in the next meeting, I thought I'd write up the state of things. While we don't feel comfortable with the build resources to move Core over to koji, we obviously have enough resources to build Extras. I'd like to work toward building Extras within Koji very soon which will have the benefits of more people using koji, more time to prepare tools around koji, and make the final merger that much easier. What will it take? Currently I've synced over all the fc6, fc6updates, and fc6 updates candidate packages and fc7 from Core into Koji. I've setup a cron job to freshen these each night (could run more often possibly). This will in essence give Koji a once a day snapshot of Core content, much like nightly rawhide gives plague a snapshot of Core content. Next we will have to import all the Extras content. We can just import the devel content since we won't necessarily need inheritance, will we? Do the devel pushes grab any FC6 content when populating the development tree? Regardless, I'd want to import them into a dist-fe7 tag, which inherits from dist-fc7, which inherits from dist-fc6. I don't want them directly in dist-fc7 yet as it will be harder to publish just the Extras packages. Once packages are imported and tagged, we can flip the Makefile.common changes so that 'make build' on devel/ will invoke koji instead of plague. Dennis Gilmore wrote a script that I packaged up in the latest koji package that will convert existing plague environments over to koji (without disrupting the plague setup). Then we'll need some software to do the actual signing + pushing of packages. I'd imagine much of the same scripts could be used, we'd just have to bolt on some code that will take the packages out of koji and drop them into a 'needsign' like queue that the push scripts could work from. It is pretty simple/straight forward to ask koji for all the latest packages (without inheritance) from a given tag. Then you could hardlink those into a needsign directory and work from there. Finally we'd need some new code around adding new packages to the collection. For the koji side, a simple call to koji add-pkg --owner is all that is needed. Of course there will also need to be some synchronization around changing ownership too, if an admin changes ownership in owners.list, they'd need to change it withink koji, koji set-pkg-owner or koji set-pkg-owner-global if changing it for all tags. Not hard, and maybe best to just do it by handish until we merge together owners.list, packagedb, and koji db. Package ownership within Bugzilla should continue to be generated from owners.list and thus not need any updating at this time. What do you all think of this plan, or the idea in general of getting Extras to use Koji now, while we wait for more hardware to be able to merge in Core? At the time of merger, since all the tags would be being kept up to date anyway, we'd just have to add all the existing Extras packages to the dist-fc7 tag, and tag all the latest dist-fe7 packages with dist-fc7, then decomission the dist-fe7 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 Thu Apr 12 15:46:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Apr 2007 17:46:25 +0200 Subject: EPEL stuff for todays (20070412) FESCO meeting In-Reply-To: <1176338462.5907.3.camel@lincoln> References: <1176338462.5907.3.camel@lincoln> Message-ID: <461E5451.2010407@leemhuis.info> Brian Pepple schrieb: > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > [...] > /topic FESCO-Meeting -- EPEL Summary of this weeks meeting: https://www.redhat.com/archives/epel-devel-list/2007-April/msg00063.html Important stuff regarding EPEL: - we should have RHEL5 on the builders soon and will tell everybody who might be waiting for a "go" signal to start for real then - there are discussions to have a official chairman for the EPEL steering committee -- is that okay (or even wanted?) by FESCo? - there were three votings by the EPEL steering committee done via the wiki; see https://www.redhat.com/archives/epel-devel-list/2007-April/msg00055.html for details and the outcome . In short: no repotags (this was decided by FESCo already months ago but came up again and was discussed again), fedora-usermgmt does not get forbidden in EPEL and the mass-rebuild will happen in a "delete repo and just rebuild everything again with RHEL5 final on the builders now"-style. Cu thl From fedora at leemhuis.info Thu Apr 12 16:12:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Apr 2007 18:12:57 +0200 Subject: Plan for tomorrows (20070412) FESCO meeting In-Reply-To: <1176338462.5907.3.camel@lincoln> References: <1176338462.5907.3.camel@lincoln> Message-ID: <461E5A89.7030705@leemhuis.info> Brian Pepple schrieb: > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > [...] > You want something to be discussed? [...] I'd like to see "what feels FESCo responsible for" discussed a bit (here and in the meeting probably, as I'm quite late in the game for todays meeting -- sorry). Reason: FESCo (as Fedora *Engineering* Steering Committee) is the successor of what was known as "Core Cabal" in the past. It members afaik handled and coordinated nearly all *engineering* tasks to get a distribution finished round about every six months. That includes (but it not limited to) stuff like freezes, delays, what gets in after the feature freeze, roadmap/pampered features, reports from the relase-manager/team and QA about test release, analyzing what went good and what went bad and needs to be improved next time; all those and a lot of other things I'm missing now the Core Cabal did in the past. FESCo as the official Core Cabal successor afaics should handle those stuff these days. But it gets rarely done -- seem the Board took care of it in the past weeks as FESCo didn't do much about the stuff mentioned above. But is that wanted? Or did it simply happen that way? Note that I complained about this on FAB-list already and discussed it a bit with Max in private. That resulted in a discussion in a board meeting two weeks ago; see https://www.redhat.com/archives/fedora-advisory-board/2007-March/msg00279.html Quoting: "'''Fedora Board and Fedora Engineering Steering Committee''' Max summarized his recent conversation with ThorstenLeemhuis in which they discussed the fact that the Fedora Board is inadvertantly poaching some of the topics that are more appropriately discussed by FESCO. Examples include (1) EPEL guildelines, (2) release schedule details, and (3) status checks on the most important Fedora 7 features. The Board needs to do a better job of *understanding* what is going on with all those items and being informed, but not necessarily making the decisions itself -- that takes away a bit from FESCO, which should have the first opportunity to act." Well, if FESCo wants to take this opportunity then I'd say it should have at least a "Fedora 7: status and what remains to be done" or similar stuff on the schedule. CU thl From ville.skytta at iki.fi Thu Apr 12 18:50:39 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 12 Apr 2007 21:50:39 +0300 Subject: Using Koji for building Extras In-Reply-To: <200704120912.33809.jkeating@redhat.com> References: <200704120912.33809.jkeating@redhat.com> Message-ID: <200704122150.39646.ville.skytta@iki.fi> On Thursday 12 April 2007, Jesse Keating wrote: Just a couple of quick questions: > While we don't feel comfortable with the build resources to move Core over > to koji, we obviously have enough resources to build Extras. Hm, in terms of package numbers inside one arch, Extras devel is over twice the size of Core devel. Just curious what makes Core's build resource demands obviously higher than Extras'? More archs, more big packages to build? > What do you all think of this plan, or the idea in general of getting > Extras to use Koji now, while we wait for more hardware to be able to merge > in Core? Hard to say; what does moving to koji mean for the Joe Average packager, and is there something in it that is required ASAP and plague doesn't do? Without knowledge of such things, I tend to think making the move at the same time for both and also making it possible for ex-Core packages to have dependencies on ex-Extras ones also at the same time would sound quite natural. Not enough info to have a strong opinion though. From bugs.michael at gmx.net Thu Apr 12 19:10:42 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 Apr 2007 21:10:42 +0200 Subject: NetworkManager* - non-trivial unowned directories Message-ID: <20070412211042.dba2402e.bugs.michael@gmx.net> Which package(s) should own these directories? => NetworkManager-gnome - 1:0.6.5-0.7.svn2547.fc7.i386 (fedora-core-development- i386) /usr/share/gnome-vpn-properties => NetworkManager-openvpn - 0.3.2-7.fc6.i386 (fedora-extras-development-i386) /etc/NetworkManager/VPN /usr/share/gnome-vpn-properties /usr/share/gnome-vpn-properties/openvpn => NetworkManager-vpnc - 1:0.6.4-3.fc7.i386 (fedora-extras-development-i386) /etc/NetworkManager/VPN /usr/share/gnome-vpn-properties /usr/share/gnome-vpn-properties/vpnc From seg at haxxed.com Thu Apr 12 19:08:55 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 12 Apr 2007 14:08:55 -0500 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <20070411113359.3b16c3e6@python3.es.egwn.lan> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244185.2976.1.camel@localhost.localdomain> <1176244769.18654.18.camel@rousalka.dyndns.org> <20070411113359.3b16c3e6@python3.es.egwn.lan> Message-ID: <1176404936.24904.4.camel@localhost.localdomain> On Wed, 2007-04-11 at 11:33 +0200, Matthias Saou wrote: > Nicolas Mailhot wrote : > > > Le mercredi 11 avril 2007 ? 00:29 +0200, Matthias Clasen a ?crit : > > > > > US-ASCII is a meaningless term. There simply is no 8-bit ASCII > > > > Sure but ASCII is frequently abused nevertheless. And human lazyness > > will "help" people choose the abusive interpretation. > > How about referring to "plain ASCII" in the guideline? Why has no one mentioned the most obvious solution. Refer to it as "7-bit ASCII". It has the word "ASCII" in it for ease of understanding, and further stresses that we mean 7 bits, not 8. It may technically be redundant, but that's pretty much the point. -------------- 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 dennis at ausil.us Thu Apr 12 19:16:56 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 12 Apr 2007 14:16:56 -0500 Subject: Using Koji for building Extras In-Reply-To: <200704122150.39646.ville.skytta@iki.fi> References: <200704120912.33809.jkeating@redhat.com> <200704122150.39646.ville.skytta@iki.fi> Message-ID: <200704121416.57149.dennis@ausil.us> On Thursday 12 April 2007 01:50:39 pm Ville Skytt? wrote: > On Thursday 12 April 2007, Jesse Keating wrote: > > Just a couple of quick questions: > > While we don't feel comfortable with the build resources to move Core > > over to koji, we obviously have enough resources to build Extras. > > Hm, in terms of package numbers inside one arch, Extras devel is over twice > the size of Core devel. Just curious what makes Core's build resource > demands obviously higher than Extras'? More archs, more big packages to > build? more big packages. kernel, OOo, Eclipse, gcc, glibc things that take a long time to build and see semi frequent builds. > > What do you all think of this plan, or the idea in general of getting > > Extras to use Koji now, while we wait for more hardware to be able to > > merge in Core? > > Hard to say; what does moving to koji mean for the Joe Average packager, > and is there something in it that is required ASAP and plague doesn't do? > Without knowledge of such things, I tend to think making the move at the > same time for both and also making it possible for ex-Core packages to have > dependencies on ex-Extras ones also at the same time would sound quite > natural. Not enough info to have a strong opinion though. for average joe package they run the script to setup the koji environment that is in the koji package. they then run make build . on thing thats different is that koji shows you the progress on the console. you dont have to watch this if you dont want to but can follow a builds progress. -- Dennis Gilmore, RHCE From jwboyer at jdub.homelinux.org Thu Apr 12 19:15:56 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 12 Apr 2007 14:15:56 -0500 Subject: Using Koji for building Extras In-Reply-To: <200704122150.39646.ville.skytta@iki.fi> References: <200704120912.33809.jkeating@redhat.com> <200704122150.39646.ville.skytta@iki.fi> Message-ID: <1176405356.6379.87.camel@zod.rchland.ibm.com> On Thu, 2007-04-12 at 21:50 +0300, Ville Skytt? wrote: > On Thursday 12 April 2007, Jesse Keating wrote: > > Just a couple of quick questions: > > > While we don't feel comfortable with the build resources to move Core over > > to koji, we obviously have enough resources to build Extras. > > Hm, in terms of package numbers inside one arch, Extras devel is over twice > the size of Core devel. Just curious what makes Core's build resource > demands obviously higher than Extras'? More archs, more big packages to > build? Things like gcc, glibc, kernel, and OO.o are huge resource users. I think OO.o can take 24 hours or more to build, which ties up a single builder all day. josh From jkeating at redhat.com Thu Apr 12 19:21:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 15:21:53 -0400 Subject: Using Koji for building Extras In-Reply-To: <200704122150.39646.ville.skytta@iki.fi> References: <200704120912.33809.jkeating@redhat.com> <200704122150.39646.ville.skytta@iki.fi> Message-ID: <200704121521.53737.jkeating@redhat.com> On Thursday 12 April 2007 14:50:39 Ville Skytt? wrote: > > While we don't feel comfortable with the build resources to move Core > > over to koji, we obviously have enough resources to build Extras. > > Hm, in terms of package numbers inside one arch, Extras devel is over twice > the size of Core devel. ?Just curious what makes Core's build resource > demands obviously higher than Extras'? ?More archs, more big packages to > build? Mostly more big packages to build and more often. Extras lacks fun things like kernel, glibc, gcc, openoffice.org, kdebase, etc... It's not unusual to see many of these hit the buildsystem during the same day, and given that each take upwards to 12 hours to build, that can cause quite the delay in other builds happening. > > What do you all think of this plan, or the idea in general of getting > > Extras to use Koji now, while we wait for more hardware to be able to > > merge in Core? > > Hard to say; what does moving to koji mean for the Joe Average packager, > and is there something in it that is required ASAP and plague doesn't do? Not required, however I'd like to get real world load on it and push the issue for getting software written around it. For Joe Average packager, not much changes. 'make build' output may look a little different, and there is a much nicer web interface to watch whats going on, and even the ability to "watch" the logs from the cli. We'll also be able to do build notifications by default to not just the person whom submitted the build, but also to the person whom owns the package built. > Without knowledge of such things, I tend to think making the move at the > same time for both and also making it possible for ex-Core packages to have > dependencies on ex-Extras ones also at the same time would sound quite > natural. ?Not enough info to have a strong opinion though. Breaking the world all at once is sometimes desired. However due to not having enough hardware we can't do that, and instead of waiting on many of these things until then, I'd rather get some of the pain done now so that when we do the merger it's actually a lot smoother and there is a lot less risk of EVERYTHING breaking all at once. -- 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 tibbs at math.uh.edu Thu Apr 12 19:21:49 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Apr 2007 14:21:49 -0500 Subject: NetworkManager* - non-trivial unowned directories In-Reply-To: <20070412211042.dba2402e.bugs.michael@gmx.net> References: <20070412211042.dba2402e.bugs.michael@gmx.net> Message-ID: >>>>> "MS" == Michael Schwendt writes: MS> Which package(s) should own these directories? => MS> => NetworkManager-openvpn - 0.3.2-7.fc6.i386 MS> (fedora-extras-development-i386) MS> /etc/NetworkManager/VPN Most likely NetworkManager. MS> /usr/share/gnome-vpn-properties Do does NetworkManager-openvpn have a dependency on NM-gnome? If so, then NM-gnome. Otherwise, probably NetworkManager itself. - J< From dcbw at redhat.com Thu Apr 12 19:39:44 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 12 Apr 2007 15:39:44 -0400 Subject: NetworkManager* - non-trivial unowned directories In-Reply-To: References: <20070412211042.dba2402e.bugs.michael@gmx.net> Message-ID: <1176406784.3247.1.camel@localhost.localdomain> On Thu, 2007-04-12 at 14:21 -0500, Jason L Tibbitts III wrote: > >>>>> "MS" == Michael Schwendt writes: > > MS> Which package(s) should own these directories? => > > MS> => NetworkManager-openvpn - 0.3.2-7.fc6.i386 > MS> (fedora-extras-development-i386) > > MS> /etc/NetworkManager/VPN > > Most likely NetworkManager. > > MS> /usr/share/gnome-vpn-properties > > Do does NetworkManager-openvpn have a dependency on NM-gnome? If so, > then NM-gnome. Otherwise, probably NetworkManager itself. The current plugins have gnome deps, but they don't _need_ to. You can write a plugin with KDE-based GUI bits or plain X gui bits. NM should own the /etc/NetworkManager/VPN directory. /usr/share/gnome-vpn-properties is less clear; but probably NetworkManager-gnome (or wherever the applet is) should own that directory. Dan > > - J< > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From dennis at ausil.us Thu Apr 12 19:49:37 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 12 Apr 2007 14:49:37 -0500 Subject: NetworkManager* - non-trivial unowned directories In-Reply-To: <1176406784.3247.1.camel@localhost.localdomain> References: <20070412211042.dba2402e.bugs.michael@gmx.net> <1176406784.3247.1.camel@localhost.localdomain> Message-ID: <200704121449.37847.dennis@ausil.us> On Thursday 12 April 2007 02:39:44 pm Dan Williams wrote: > On Thu, 2007-04-12 at 14:21 -0500, Jason L Tibbitts III wrote: > > >>>>> "MS" == Michael Schwendt writes: > > > > MS> Which package(s) should own these directories? => > > > > MS> => NetworkManager-openvpn - 0.3.2-7.fc6.i386 > > MS> (fedora-extras-development-i386) > > > > MS> /etc/NetworkManager/VPN > > > > Most likely NetworkManager. > > > > MS> /usr/share/gnome-vpn-properties > > > > Do does NetworkManager-openvpn have a dependency on NM-gnome? If so, > > then NM-gnome. Otherwise, probably NetworkManager itself. > > The current plugins have gnome deps, but they don't _need_ to. You can > write a plugin with KDE-based GUI bits or plain X gui bits. > > NM should own the /etc/NetworkManager/VPN directory. > > /usr/share/gnome-vpn-properties is less clear; but probably > NetworkManager-gnome (or wherever the applet is) should own that > directory. > the next build of knetworkmanger has kde vpn plugins. As soon as i work out why it fails to build on i386 it will be out. -- Dennis Gilmore, RHCE From buildsys at fedoraproject.org Thu Apr 12 20:52:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 12 Apr 2007 16:52:50 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-12 Message-ID: <20070412205250.35B95152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mr.ecik AT gmail.com: kadu FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) kadu: mr.ecik AT gmail.com FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) From Jerry.James at usu.edu Thu Apr 12 21:07:41 2007 From: Jerry.James at usu.edu (Jerry James) Date: Thu, 12 Apr 2007 15:07:41 -0600 Subject: Moodle: language packs and FC-4 In-Reply-To: (Jason L. Tibbitts, III's message of "Wed, 11 Apr 2007 22:03:13 -0500") References: Message-ID: Thanks for the feedback, Ville and Jason. Incidentally, I should publicly note at some point that my presence here is all Ville's fault. :-) If he hadn't prodded me, I'd still be doing this: http://www.cs.usu.edu/~jerry/Projects/RPMS/ I hope to move many of the RPMs there to Fedora (although some of them cannot be moved for licensing reasons). Jason L Tibbitts III , on Wed, 11 Apr 2007 at 22:03:13 -0500 you wrote: >>>>>> "JJ" == Jerry James writes: > JJ> 1) Download all of the language files and include them in one > JJ> monolithic moodle SRPM. Split out the installation and use files > JJ> for each language into a language subpackage. This lets us keep > JJ> all the files for a particular language in one place, but means > JJ> that anytime an individual language file gets updated, we have to > JJ> rebuild the whole thing. > > That may not be much of a problem if the language files don't change > much more often than the package itself. I'm a pretty new moodle user, so I don't yet have a feel for how often they change. Plus, I've been ignoring the language packs anyway, since I am a native U.S.an teaching at a U.S. school. > JJ> 2) Embrace the fact that the installation language files are small > JJ> (a few hundred bytes to a few K apiece), and partially unnecessary > JJ> anyway. Just put them into the main moodle package (once!). > JJ> Create separate SRPMs for each language file with the date stamp > JJ> for the version number. Now language packs can be updated > JJ> individually, but this also means that I will suddenly be the > JJ> maintainer for 60+ additional packages in which I have no personal > JJ> interest. > > I'd expect the maintenance overhead of one of these to be low, but > having to rev 60 of them at a time might be just plain annoying. That's my worry, yes. > I think the final decision rests with you; you need to determine how > much time you can invest and how much process you're willing to put up > with. Perhaps you can find someone willing to assist you in > maintaining these? I suppose that if nobody is willing to do so, you > could simply drop those languages in which you're not interested. I don't want to spend much time on the language packs, since I will never use them myself. I'm going to try option (1) and see how it goes. I probably won't be terribly snappy about updating language packs off of the moodle release cycle, though. Thanks, -- Jerry James, Assistant Professor Jerry.James at usu.edu Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University From dcbw at redhat.com Fri Apr 13 01:28:32 2007 From: dcbw at redhat.com (Dan Williams) Date: Thu, 12 Apr 2007 21:28:32 -0400 Subject: NetworkManager* - non-trivial unowned directories In-Reply-To: <200704121449.37847.dennis@ausil.us> References: <20070412211042.dba2402e.bugs.michael@gmx.net> <1176406784.3247.1.camel@localhost.localdomain> <200704121449.37847.dennis@ausil.us> Message-ID: <1176427712.18007.0.camel@localhost.localdomain> On Thu, 2007-04-12 at 14:49 -0500, Dennis Gilmore wrote: > On Thursday 12 April 2007 02:39:44 pm Dan Williams wrote: > > On Thu, 2007-04-12 at 14:21 -0500, Jason L Tibbitts III wrote: > > > >>>>> "MS" == Michael Schwendt writes: > > > > > > MS> Which package(s) should own these directories? => > > > > > > MS> => NetworkManager-openvpn - 0.3.2-7.fc6.i386 > > > MS> (fedora-extras-development-i386) > > > > > > MS> /etc/NetworkManager/VPN > > > > > > Most likely NetworkManager. > > > > > > MS> /usr/share/gnome-vpn-properties > > > > > > Do does NetworkManager-openvpn have a dependency on NM-gnome? If so, > > > then NM-gnome. Otherwise, probably NetworkManager itself. > > > > The current plugins have gnome deps, but they don't _need_ to. You can > > write a plugin with KDE-based GUI bits or plain X gui bits. > > > > NM should own the /etc/NetworkManager/VPN directory. > > > > /usr/share/gnome-vpn-properties is less clear; but probably > > NetworkManager-gnome (or wherever the applet is) should own that > > directory. > > > the next build of knetworkmanger has kde vpn plugins. As soon as i work out > why it fails to build on i386 it will be out. Great! I'd imagine they have some other directory where knetworkmanager can find the UI bits? Dan From dennis at ausil.us Fri Apr 13 02:37:38 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 12 Apr 2007 21:37:38 -0500 Subject: NetworkManager* - non-trivial unowned directories In-Reply-To: <1176427712.18007.0.camel@localhost.localdomain> References: <20070412211042.dba2402e.bugs.michael@gmx.net> <200704121449.37847.dennis@ausil.us> <1176427712.18007.0.camel@localhost.localdomain> Message-ID: <200704122137.47198.dennis@ausil.us> Once upon a time Thursday 12 April 2007, Dan Williams wrote: > On Thu, 2007-04-12 at 14:49 -0500, Dennis Gilmore wrote: > > the next build of knetworkmanger has kde vpn plugins. As soon as i work > > out why it fails to build on i386 it will be out. > > Great! I'd imagine they have some other directory where knetworkmanager > can find the UI bits? > > Dan /usr/lib64/kde3/knetworkmanager_vpnc.so.0 is where the vpnc plugin lives on x86_64 the rest are in the same location so yep its differnet Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caolanm at redhat.com Fri Apr 13 07:21:12 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 13 Apr 2007 08:21:12 +0100 Subject: Using Koji for building Extras In-Reply-To: <1176405356.6379.87.camel@zod.rchland.ibm.com> References: <200704120912.33809.jkeating@redhat.com> <200704122150.39646.ville.skytta@iki.fi> <1176405356.6379.87.camel@zod.rchland.ibm.com> Message-ID: <1176448872.16304.10.camel@localhost.localdomain> On Thu, 2007-04-12 at 14:15 -0500, Josh Boyer wrote: > Things like gcc, glibc, kernel, and OO.o are huge resource users. > I think OO.o can take 24 hours or more to build, which ties up a single > builder all day. That's the bad old days of FC-5 and hideous 16/23 hour i386/ppc builds. With some (if I do say so myself) awesome reimplementation of the java base help file building and parsing into a c++ libxsltproc based one and a pile of multiproc build fixes I can both reliably parallel build now and can zip through the multi langpack build in about 3/6 hours depending on architecture. But there's no denying that it's a big intensive build which'll tie up a number of machines. C. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 13 10:05:21 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 13 Apr 2007 12:05:21 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176404936.24904.4.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244185.2976.1.camel@localhost.localdomain> <1176244769.18654.18.camel@rousalka.dyndns.org> <20070411113359.3b16c3e6@python3.es.egwn.lan> <1176404936.24904.4.camel@localhost.localdomain> Message-ID: <20070413120521.5aae4411@python3.es.egwn.lan> Callum Lerwick wrote : > On Wed, 2007-04-11 at 11:33 +0200, Matthias Saou wrote: > > Nicolas Mailhot wrote : > > > > > Le mercredi 11 avril 2007 ? 00:29 +0200, Matthias Clasen a ?crit : > > > > > > > US-ASCII is a meaningless term. There simply is no 8-bit ASCII > > > > > > Sure but ASCII is frequently abused nevertheless. And human lazyness > > > will "help" people choose the abusive interpretation. > > > > How about referring to "plain ASCII" in the guideline? > > Why has no one mentioned the most obvious solution. Refer to it as > "7-bit ASCII". It has the word "ASCII" in it for ease of understanding, > and further stresses that we mean 7 bits, not 8. It may technically be > redundant, but that's pretty much the point. In the very first reply to the thread, Nicolas suggested just that, and it's what started the discussion :-) Nicolas : "Shouldn't this be clarified as 7-bit ASCII ?" Others : ASCII is necessarily 7-bit!! ... Which brought me to suggest "plain ASCII", as "plain" suggests "no extensions", but doesn't go into any technical details, and it's a terminology I'm quite sure I already came across a few times. 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.51 0.27 0.18 From jkeating at redhat.com Fri Apr 13 12:52:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 08:52:17 -0400 Subject: Using Koji for building Extras In-Reply-To: <1176448872.16304.10.camel@localhost.localdomain> References: <200704120912.33809.jkeating@redhat.com> <1176405356.6379.87.camel@zod.rchland.ibm.com> <1176448872.16304.10.camel@localhost.localdomain> Message-ID: <200704130852.17615.jkeating@redhat.com> On Friday 13 April 2007 03:21:12 Caolan McNamara wrote: > That's the bad old days of FC-5 and hideous 16/23 hour i386/ppc builds. > With some (if I do say so myself) awesome reimplementation of the java > base help file building and parsing into a c++ libxsltproc based one and > a pile of multiproc build fixes I can both reliably parallel build now > and can zip through the multi langpack build in about 3/6 hours > depending on architecture. But there's no denying that it's a big > intensive build which'll tie up a number of machines. It still takes anywhere from 6 to 12 hours to build through our internal build system, by that I mean all arches finish that we build for. -- 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 ssorce at redhat.com Fri Apr 13 13:20:53 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Apr 2007 09:20:53 -0400 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <20070413120521.5aae4411@python3.es.egwn.lan> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244185.2976.1.camel@localhost.localdomain> <1176244769.18654.18.camel@rousalka.dyndns.org> <20070411113359.3b16c3e6@python3.es.egwn.lan> <1176404936.24904.4.camel@localhost.localdomain> <20070413120521.5aae4411@python3.es.egwn.lan> Message-ID: <1176470453.24049.9.camel@willson> On Fri, 2007-04-13 at 12:05 +0200, Matthias Saou wrote: > Callum Lerwick wrote : > > > On Wed, 2007-04-11 at 11:33 +0200, Matthias Saou wrote: > > > Nicolas Mailhot wrote : > > > > > > > Le mercredi 11 avril 2007 ? 00:29 +0200, Matthias Clasen a ?crit : > > > > > > > > > US-ASCII is a meaningless term. There simply is no 8-bit ASCII > > > > > > > > Sure but ASCII is frequently abused nevertheless. And human lazyness > > > > will "help" people choose the abusive interpretation. > > > > > > How about referring to "plain ASCII" in the guideline? > > > > Why has no one mentioned the most obvious solution. Refer to it as > > "7-bit ASCII". It has the word "ASCII" in it for ease of understanding, > > and further stresses that we mean 7 bits, not 8. It may technically be > > redundant, but that's pretty much the point. > > In the very first reply to the thread, Nicolas suggested just that, and > it's what started the discussion :-) > > Nicolas : "Shouldn't this be clarified as 7-bit ASCII ?" > > Others : ASCII is necessarily 7-bit!! > > ... > > Which brought me to suggest "plain ASCII", as "plain" suggests "no > extensions", but doesn't go into any technical details, and it's a > terminology I'm quite sure I already came across a few times. As said before, just tell people to do "man ascii". There is all you need to understand which characters are in the ASCII set. Simo. From limb at jcomserv.net Fri Apr 13 14:24:26 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 13 Apr 2007 09:24:26 -0500 (CDT) Subject: NX/FreeNX maintainer: AWOL? Message-ID: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> I've been trying to follow up on some nx bugs, and have had little success getting a hold of Richard A. Stout, zipsonic at gmail.com, the maintainer of both packages. These are the only two packages he maintains, and there are several untouched NEW bugs. If anyone knows how to contact him, please direct him to the AWOL bug I filed 2 weeks ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 I hope he's out there, I use freenx every day. . . Jon Ciesla P.S. I assume since f-e-l is being closed this weekend, that AWOL messages should now go to f-m. I can edit the wiki to reflect this if this is correct. -- novus ordo absurdum From sundaram at fedoraproject.org Fri Apr 13 15:09:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Apr 2007 20:39:10 +0530 Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> Message-ID: <461F9D16.3070101@fedoraproject.org> Jon Ciesla wrote: > P.S. I assume since f-e-l is being closed this weekend, that AWOL messages > should now go to f-m. I can edit the wiki to reflect this if this is > correct. That's correct. Rahul From seg at haxxed.com Fri Apr 13 16:10:49 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 13 Apr 2007 11:10:49 -0500 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <20070413120521.5aae4411@python3.es.egwn.lan> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244185.2976.1.camel@localhost.localdomain> <1176244769.18654.18.camel@rousalka.dyndns.org> <20070411113359.3b16c3e6@python3.es.egwn.lan> <1176404936.24904.4.camel@localhost.localdomain> <20070413120521.5aae4411@python3.es.egwn.lan> Message-ID: <1176480649.6663.0.camel@max> On Fri, 2007-04-13 at 12:05 +0200, Matthias Saou wrote: > In the very first reply to the thread, Nicolas suggested just that, and > it's what started the discussion :-) > > Nicolas : "Shouldn't this be clarified as 7-bit ASCII ?" > > Others : ASCII is necessarily 7-bit!! Everyone but Nicolas and me is insane then. ;P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Fri Apr 13 16:57:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 13 Apr 2007 18:57:59 +0200 Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> Message-ID: <20070413165759.GD32753@neu.nirvana> On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: > I've been trying to follow up on some nx bugs, and have had little success > getting a hold of Richard A. Stout, zipsonic at gmail.com, the maintainer of > both packages. These are the only two packages he maintains, and there > are several untouched NEW bugs. > > If anyone knows how to contact him, The email you quote above is Rick's mail, all right. I've added him to the Cc. If Rick is not available anymore for nx/freenx I would like to pick these up. > please direct him to the AWOL bug I filed 2 weeks > ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 Is that's the procedure how AWOLs are probed? Just curious. > I hope he's out there, I use freenx every day. . . > > Jon Ciesla > > P.S. I assume since f-e-l is being closed this weekend, that AWOL messages > should now go to f-m. I can edit the wiki to reflect this if this is > correct. > -- 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 limb at jcomserv.net Fri Apr 13 17:08:30 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 13 Apr 2007 12:08:30 -0500 (CDT) Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <20070413165759.GD32753@neu.nirvana> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> Message-ID: <4088.192.168.0.4.1176484110.squirrel@zanoni> It is. I've edited the wiki. http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers > On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: >> I've been trying to follow up on some nx bugs, and have had little >> success >> getting a hold of Richard A. Stout, zipsonic at gmail.com, the maintainer >> of >> both packages. These are the only two packages he maintains, and there >> are several untouched NEW bugs. >> >> If anyone knows how to contact him, > > The email you quote above is Rick's mail, all right. I've added him to > the Cc. If Rick is not available anymore for nx/freenx I would like to > pick these up. > >> please direct him to the AWOL bug I filed 2 weeks >> ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > > Is that's the procedure how AWOLs are probed? Just curious. > >> I hope he's out there, I use freenx every day. . . >> >> Jon Ciesla >> >> P.S. I assume since f-e-l is being closed this weekend, that AWOL >> messages >> should now go to f-m. I can edit the wiki to reflect this if this is >> correct. >> > > -- > Axel.Thimm at ATrpms.net > -- novus ordo absurdum From tibbs at math.uh.edu Fri Apr 13 17:44:28 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Apr 2007 12:44:28 -0500 Subject: extras-list references in the wiki (Was: NX/FreeNX maintainer: AWOL?) In-Reply-To: <4088.192.168.0.4.1176484110.squirrel@zanoni> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <4088.192.168.0.4.1176484110.squirrel@zanoni> Message-ID: On the topic of fixing dangling fedora-extras-list references in the wiki, here are some pages I found with a quick search: http://fedoraproject.org/wiki/PostIsOffTopic?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Packaging/Guidelines?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/Policy/KernelModules?highlight=%28extras-list%29 http://fedoraproject.org/wiki/DocsProject/NewWriters?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Communicate?highlight=%28extras-list%29 http://fedoraproject.org/wiki/PackagingDrafts/KernelModulesWithKverInName?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Packaging/NamingGuidelines?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/TreeMaintenance?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/SelfIntroduction?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/Schedule/HowToGetSomethingRealized?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/Schedule/FixStuffThatNeedsFixing?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/RepositoryMixingProblems?highlight=%28extras-list%29 http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages?highlight=%28extras-list%29 Obviously some of these will have to go through the proper committees to be fixed; I'll work on the ones in the packaging guidelines. - J< From belegdol at gmail.com Fri Apr 13 19:09:52 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 13 Apr 2007 20:09:52 +0100 Subject: How to load a kernel module automatically? In-Reply-To: <200704041505.00482.ville.skytta@iki.fi> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> Message-ID: <461FD580.60503@gmail.gom> Here is the SPEC I wrapped up. I borrowed a bit from udev. The only problem is that the module won't be loaded until next restart. Personally, I don't think it is that big problem, I could just add Readme.Fedora informing about that. It is good not to forget the attachment ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: thinkfinger.spec.bz2 Type: application/x-bzip Size: 1666 bytes Desc: not available URL: From notting at redhat.com Fri Apr 13 19:19:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Apr 2007 15:19:06 -0400 Subject: How to load a kernel module automatically? In-Reply-To: <461FD580.60503@gmail.gom> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> <461FD580.60503@gmail.gom> Message-ID: <20070413191906.GA7462@nostromo.devel.redhat.com> Julian Sikorski (belegdol at gmail.com) said: > Here is the SPEC I wrapped up. I borrowed a bit from udev. The only > problem is that the module won't be loaded until next restart. > Personally, I don't think it is that big problem, I could just add > Readme.Fedora informing about that. (deranged idea) Why not make a five-line kernel module attached to the USB device ID for this device that loads uinput? Bill From belegdol at gmail.com Fri Apr 13 19:24:32 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 13 Apr 2007 20:24:32 +0100 Subject: How to load a kernel module automatically? In-Reply-To: <20070413191906.GA7462@nostromo.devel.redhat.com> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> <461FD580.60503@gmail.gom> <20070413191906.GA7462@nostromo.devel.redhat.com> Message-ID: <461FD8F0.3010108@gmail.gom> Bill Nottingham napisa?(a): > Julian Sikorski (belegdol at gmail.com) said: >> Here is the SPEC I wrapped up. I borrowed a bit from udev. The only >> problem is that the module won't be loaded until next restart. >> Personally, I don't think it is that big problem, I could just add >> Readme.Fedora informing about that. > > (deranged idea) > > Why not make a five-line kernel module attached to the USB device > ID for this device that loads uinput? > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Sounds good. Can you shed some more light? From belegdol at gmail.com Fri Apr 13 19:05:23 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 13 Apr 2007 20:05:23 +0100 Subject: How to load a kernel module automatically? In-Reply-To: <200704041505.00482.ville.skytta@iki.fi> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> Message-ID: <461FD473.80207@gmail.gom> Here is the SPEC I wrapped up. I borrowed a bit from udev. The only problem is that the module won't be loaded until next restart. Personally, I don't think it is that big problem, I could just add Readme.Fedora informing about that. From belegdol at gmail.com Fri Apr 13 19:29:21 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Fri, 13 Apr 2007 20:29:21 +0100 Subject: How to load a kernel module automatically? In-Reply-To: <20070413191906.GA7462@nostromo.devel.redhat.com> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> <461FD580.60503@gmail.gom> <20070413191906.GA7462@nostromo.devel.redhat.com> Message-ID: <461FDA11.1050800@gmail.gom> Bill Nottingham napisa?(a): > Julian Sikorski (belegdol at gmail.com) said: >> Here is the SPEC I wrapped up. I borrowed a bit from udev. The only >> problem is that the module won't be loaded until next restart. >> Personally, I don't think it is that big problem, I could just add >> Readme.Fedora informing about that. > > (deranged idea) > > Why not make a five-line kernel module attached to the USB device > ID for this device that loads uinput? > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > I now checked what deranged means :) I don't think I will be able to write a kmod, and IMO it would be a PITA to maintain... From jkeating at redhat.com Fri Apr 13 19:34:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 15:34:15 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th Message-ID: <200704131534.15954.jkeating@redhat.com> This will also mark the point in which I'd like to enter a continual slushy state. Only bugfixes going in, with low risk to breaking other things. See http://fedoraproject.org/wiki/Releases/DevelFreezePolicy for policy on getting things tagged for the freeze tag for now until the end of the F7 cycle. -- 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 j.w.r.degoede at hhs.nl Fri Apr 13 20:15:34 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 13 Apr 2007 22:15:34 +0200 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <200704131534.15954.jkeating@redhat.com> References: <200704131534.15954.jkeating@redhat.com> Message-ID: <461FE4E6.4050701@hhs.nl> Jesse Keating wrote: > This will also mark the point in which I'd like to enter a continual slushy > state. Only bugfixes going in, with low risk to breaking other things. > > See http://fedoraproject.org/wiki/Releases/DevelFreezePolicy for policy on > getting things tagged for the freeze tag for now until the end of the F7 > cycle. > Hmm, thats the same document as for the test3 freeze and doesn't talk about any tagging. When I issue (bugfix) updates to any of my packages on or after the 17th, do I then need todo anything special to get them into test4 and/or final? When I issue non-bugfix updates can I still build them or must I wait till Fedora 7 final and an F7 branch is created before building (in the new devel then) non bugfix updates? Regards, Hans From jkeating at redhat.com Fri Apr 13 20:11:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Apr 2007 16:11:02 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <461FE4E6.4050701@hhs.nl> References: <200704131534.15954.jkeating@redhat.com> <461FE4E6.4050701@hhs.nl> Message-ID: <200704131611.02618.jkeating@redhat.com> On Friday 13 April 2007 16:15:34 Hans de Goede wrote: > Hmm, thats the same document as for the test3 freeze and doesn't talk about > any tagging. When I issue (bugfix) updates to any of my packages on or > after the 17th, do I then need todo anything special to get them into test4 > and/or final? It's not the same document, I made some changes. The test3 document was FeatureFreeze, and tagging isn't mentioned there because the use of a freeze tag isn't in place. Until such time as Extras is built in Koji, or Core and Extras merge and are built in Koji, as an Extras packager you don't have to worry about this. _I_ worry about it because I can't control what goes into Extras or what doesn't go into Extras during the freeze. But that's a price I'm willing to pay to let Extras be extras until we merge, or get a new buildsystem in place that makes this easy. > When I issue non-bugfix updates can I still build them or must I wait till > Fedora 7 final and an F7 branch is created before building (in the new > devel then) non bugfix updates? This is made a bit difficult by how our package SCM works. Ideally you'd be able to start doing non-bugfix updates somewhere and perhaps even build them, but they wouldn't necessarily go into rawhide. It would also not get in the way of doing any bugfixes that are needed for the release we're trying to get out. Alas we don't necessarily have that right now, without using real cvs branching, although you could do that. Ideally you'd keep devel/ HEAD free of any non-bugfix updates until it's branched off to F-7/ and then you'd be free to do whatever you want with devel/. Since we can't create F-7/ directories from the tag that was used to produce the package that went out in F-7, we have to make it from whatever is in devel/ HEAD at the time of the branch, and you could wind up with content in F-7/ that didn't actually go out in F7. -- 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 notting at redhat.com Fri Apr 13 20:13:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 Apr 2007 16:13:16 -0400 Subject: How to load a kernel module automatically? In-Reply-To: <461FD8F0.3010108@gmail.gom> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> <461FD580.60503@gmail.gom> <20070413191906.GA7462@nostromo.devel.redhat.com> <461FD8F0.3010108@gmail.gom> Message-ID: <20070413201316.GB4590@nostromo.devel.redhat.com> Julian Sikorski (belegdol at gmail.com) said: > Sounds good. Can you shed some more light? It was sort of a joke, but if you want uinput to load automatically, you could add something like the attached. It's a pretty gross layering violation, though. If you want to do it directly in udev, instead, something like: BUS=="usb", SYSFS{idProduct}=="0483", SYSFS{idVendor}=="2016", RUN+="/sbin/modprobe uinput" in a /etc/udev/rules.d rules file should work. Bill -------------- next part -------------- --- linux-2.6.20.noarch/drivers/input/misc/uinput.c.foo 2007-04-13 15:33:56.000000000 -0400 +++ linux-2.6.20.noarch/drivers/input/misc/uinput.c 2007-04-13 15:42:28.000000000 -0400 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include #include @@ -39,6 +40,16 @@ #include #include +#define VENDOR_ID_UPEK 0x0483 +#define PRODUCT_ID_THINKFINGER 0x2016 + +static struct usb_device_id uinput_table[] = { + {USB_DEVICE(VENDOR_ID_UPEK, PRODUCT_ID_THINKFINGER)}, + {} +}; + +MODULE_DEVICE_TABLE(usb, uinput_table); + static int uinput_dev_event(struct input_dev *dev, unsigned int type, unsigned int code, int value) { struct uinput_device *udev; From a.badger at gmail.com Fri Apr 13 20:15:51 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 13 Apr 2007 13:15:51 -0700 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> Message-ID: <1176495351.11234.91.camel@localhost.localdomain> On Wed, 2007-04-11 at 09:48 +0200, Nicolas Mailhot wrote: > Le Mer 11 avril 2007 08:55, Toshio Kuratomi a ?crit : > > Basically, I think a good portion of anglo-centric packagers won't know > > what the relationship is between ASCII and UTF-8. > > Sure. But a good portion of anglo-centric packagers won't know what ASCII > is either. Try to poll people someday you'll be surprised. > So true :-( Here's the latest attempt. Reference the ASCII picture instead of the full wikipedia page. Tell people to look at it. == 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 nicolas.mailhot at laposte.net Fri Apr 13 21:27:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Apr 2007 23:27:40 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176495351.11234.91.camel@localhost.localdomain> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> <1176495351.11234.91.camel@localhost.localdomain> Message-ID: <1176499660.31398.1.camel@rousalka.dyndns.org> Le vendredi 13 avril 2007 ? 13:15 -0700, Toshio Kuratomi a ?crit : > On Wed, 2007-04-11 at 09:48 +0200, Nicolas Mailhot wrote: > > Le Mer 11 avril 2007 08:55, Toshio Kuratomi a ?crit : > > > Basically, I think a good portion of anglo-centric packagers won't know > > > what the relationship is between ASCII and UTF-8. > > > > Sure. But a good portion of anglo-centric packagers won't know what ASCII > > is either. Try to poll people someday you'll be surprised. > > > So true :-( > > Here's the latest attempt. Reference the ASCII picture instead of the > full wikipedia page. Tell people to look at it. Thank you very much, this one is much clearer! A picture speaks better than a thousand words. -- 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 j.w.r.degoede at hhs.nl Sat Apr 14 07:25:56 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 14 Apr 2007 09:25:56 +0200 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <200704131611.02618.jkeating@redhat.com> References: <200704131534.15954.jkeating@redhat.com> <461FE4E6.4050701@hhs.nl> <200704131611.02618.jkeating@redhat.com> Message-ID: <46208204.4020203@hhs.nl> Jesse Keating wrote: > On Friday 13 April 2007 16:15:34 Hans de Goede wrote: >> Hmm, thats the same document as for the test3 freeze and doesn't talk about >> any tagging. When I issue (bugfix) updates to any of my packages on or >> after the 17th, do I then need todo anything special to get them into test4 >> and/or final? > > It's not the same document, I made some changes. The test3 document was > FeatureFreeze, and tagging isn't mentioned there because the use of a freeze > tag isn't in place. > > Until such time as Extras is built in Koji, or Core and Extras merge and are > built in Koji, as an Extras packager you don't have to worry about this. _I_ > worry about it because I can't control what goes into Extras or what doesn't > go into Extras during the freeze. But that's a price I'm willing to pay to > let Extras be extras until we merge, or get a new buildsystem in place that > makes this easy. > >> When I issue non-bugfix updates can I still build them or must I wait till >> Fedora 7 final and an F7 branch is created before building (in the new >> devel then) non bugfix updates? > > This is made a bit difficult by how our package SCM works. Ideally you'd be > able to start doing non-bugfix updates somewhere and perhaps even build them, > but they wouldn't necessarily go into rawhide. It would also not get in the > way of doing any bugfixes that are needed for the release we're trying to get > out. Alas we don't necessarily have that right now, without using real cvs > branching, although you could do that. Ideally you'd keep devel/ HEAD free > of any non-bugfix updates until it's branched off to F-7/ and then you'd be > free to do whatever you want with devel/. Since we can't create F-7/ > directories from the tag that was used to produce the package that went out > in F-7, we have to make it from whatever is in devel/ HEAD at the time of the > branch, and you could wind up with content in F-7/ that didn't actually go > out in F7. > Thanks for the long answer, but you didn't make things much clearer for me. Let me try to rephrase the questions, and also although the why is of course very interesting could you please only answer with the how to make things clearer (and hopefully get something we can stick in the wiki for now). Question 1: If I issue a bugfix only release to an extras package do I need todo anything special for it to make the Fedora 7 final spin (still assuming a merged Fedora 7 here) Question 2: If I want to make some new / exciting changes which might very well break things, can I put those in CVS somewhere now, or should I wait till a F7 cvs branch is created and only then commit these changes to the devel branch. IOW, should I do this as it has been done with extras the last few releases: hold back any risky packages updates until after the branch? Thanks & Regards, Hans From triad at df.lth.se Sat Apr 14 09:45:02 2007 From: triad at df.lth.se (Linus Walleij) Date: Sat, 14 Apr 2007 11:45:02 +0200 (CEST) Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <200704131534.15954.jkeating@redhat.com> References: <200704131534.15954.jkeating@redhat.com> Message-ID: I think I have the same question as Hans here, is it: 1. Jesse tags all packages that are to go in F7 in CVS at the 17th with some F7-tag and what you need permission for is to bump that tag to a later .spec/sources etc. Or is it: 2. On the 17th and until F7 branch off, the living CVS devel branch is going to be == F7, so don't make any non-bugfix changes in devel until we finally branch! This is all I wanna know... Linus From buildsys at fedoraproject.org Sat Apr 14 10:03:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 14 Apr 2007 06:03:02 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-14 Message-ID: <20070414100302.23700152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): gnome-applet-vm FC6-updates > FC7 (0:0.1.2-1 > 0:0.1.0-2.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) karlthered AT gmail.com: listen FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mr.ecik AT gmail.com: kadu FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) thomas AT apestaart.org: flumotion FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) ---------------------------------------------------------------------- flumotion: thomas AT apestaart.org FE5 > FE6 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) FE5 > FE7 (0:0.2.3-1.fc5 > 0:0.2.1-3.fc6) gnome-applet-vm: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.1.2-1 > 0:0.1.0-2.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) kadu: mr.ecik AT gmail.com FE5 > FE7 (0:0.5.0-2.fc5 > 0:0.5.0-1.fc7) FE6 > FE7 (0:0.5.0-2.fc6 > 0:0.5.0-1.fc7) listen: karlthered AT gmail.com FE6 > FE7 (0:0.5-13.fc6 > 0:0.5-12.svn657.fc7.2) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) From jasperhartline at adelphia.net Sat Apr 14 10:20:13 2007 From: jasperhartline at adelphia.net (Jasper Hartline) Date: Sat, 14 Apr 2007 05:20:13 -0500 Subject: Message from Jasper Hartline (autopsy) Message-ID: <4620AADD.1060505@adelphia.net> Hello. I'm currently the lead developer for the Kadischi project seen here: http://fedoraproject.org/wiki/Kadischi I'm in the cvsdevel group and am following the new package process from the wiki and the join process for new packagers. I intend to take over Kadischi in Extras and also take control of the bugzilla entries filed for Kadischi since Chitlesh Goorah (cgoorah) has abandoned the project. I have had errors with plague-client since I am not in the cvsextras group I thin it is called. The wiki directs me to discuss it on this list. Since I'm a new packager I am curious if someone would want to sponsor me or help me continue the package process so I can complete these tasks. The review request for the package is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236162 Please let me know what I can do. Thanks. J. Hartline From belegdol at gmail.com Sat Apr 14 10:34:40 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sat, 14 Apr 2007 11:34:40 +0100 Subject: How to load a kernel module automatically? In-Reply-To: <20070413201316.GB4590@nostromo.devel.redhat.com> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> <461FD580.60503@gmail.gom> <20070413191906.GA7462@nostromo.devel.redhat.com> <461FD8F0.3010108@gmail.gom> <20070413201316.GB4590@nostromo.devel.redhat.com> Message-ID: <4620AE40.5030702@gmail.gom> Bill Nottingham napisa?(a): > Julian Sikorski (belegdol at gmail.com) said: >> Sounds good. Can you shed some more light? > > It was sort of a joke, but if you want uinput to load automatically, > you could add something like the attached. It's a pretty gross layering > violation, though. > > If you want to do it directly in udev, instead, something like: > > BUS=="usb", SYSFS{idProduct}=="0483", SYSFS{idVendor}=="2016", RUN+="/sbin/modprobe uinput" > > in a /etc/udev/rules.d rules file should work. > > Bill > You think it a better idea than /etc/sysconfig/modules scriptlet? If so, I will switch to this solution. Regards, Julian From jkeating at redhat.com Sat Apr 14 11:05:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Apr 2007 07:05:38 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <46208204.4020203@hhs.nl> References: <200704131534.15954.jkeating@redhat.com> <200704131611.02618.jkeating@redhat.com> <46208204.4020203@hhs.nl> Message-ID: <200704140705.43381.jkeating@redhat.com> On Saturday 14 April 2007 03:25:56 Hans de Goede wrote: > Question 1: > If I issue a bugfix only release to an extras package do I need todo > anything special for it to make the Fedora 7 final spin (still assuming a > merged Fedora 7 here) If merged, yes. You'd have to follow the directions from http://fedoraproject.org/wiki/Releases/DevelFreezePolicy (which could change as we actually start using it more and more). Due to the way that I compose things from Koji, I create a "freeze" tag and do composes based on packages that are tagged with this. Any build done from devel/ will not get this tag automatically, it must be applied by a member of the release engineering team. Anything that did not get tagged will wind up in the next rawhide, when we open it up for 8. > Question 2: > If I want to make some new / exciting changes which might very well break > things, can I put those in CVS somewhere now, or should I wait till a F7 > cvs branch is created and only then commit these changes to the devel > branch. IOW, should I do this as it has been done with extras the last few > releases: hold back any risky packages updates until after the branch? Yes, continuing to do what you've done before is the best strategy for now. -- 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 Sat Apr 14 11:09:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Apr 2007 07:09:23 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: References: <200704131534.15954.jkeating@redhat.com> Message-ID: <200704140709.23970.jkeating@redhat.com> On Saturday 14 April 2007 05:45:02 Linus Walleij wrote: > I think I have the same question as Hans here, is it: > > 1. Jesse tags all packages that are to go in F7 in CVS at the 17th with > ? ? some F7-tag and what you need permission for is to bump that tag to a > ? ? later .spec/sources etc. > > Or is it: > > 2. On the 17th and until F7 branch off, the living CVS devel branch is > ? ? going to be == F7, so don't make any non-bugfix changes in devel until > ? ? we finally branch! > > This is all I wanna know... It's almost both. I will be creating an f7-gold or what have you tag in the build system. As of the freeze day, I will tag all the latest builds with said tag. Anything you do in devel/ and build will still go to a 'dist-fc7' tag (I may actually start sending them to dist-fc8, not sure yet, need to discuss with release team), however during the freeze, rawhide will only pull packages tagged with 'fc7-gold'. In order to get a build you've done into rawhide and into the final Fedora 7 release, you must follow the policy http://fedoraproject.org/wiki/Releases/DevelFreezePolicy . At the same time, CVS has not been branched yet, so you should keep the devel/ branch free of any non-bugfix changes until such time that we branch CVS. When the branch happens has not been decided yet, we'll need to discuss that with the rel-eng team. -- 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 Sat Apr 14 11:22:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Apr 2007 07:22:51 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <200704140709.23970.jkeating@redhat.com> References: <200704131534.15954.jkeating@redhat.com> <200704140709.23970.jkeating@redhat.com> Message-ID: <200704140722.51501.jkeating@redhat.com> On Saturday 14 April 2007 07:09:23 Jesse Keating wrote: > It's almost both. > > I will be creating an f7-gold or what have you tag in the build system. ?As > of the freeze day, I will tag all the latest builds with said tag. > ?Anything you do in devel/ and build will still go to a 'dist-fc7' tag (I > may actually start sending them to dist-fc8, not sure yet, need to discuss > with release team), however during the freeze, rawhide will only pull > packages tagged with 'fc7-gold'. ?In order to get a build you've done into > rawhide and into the final Fedora 7 release, you must follow the policy > http://fedoraproject.org/wiki/Releases/DevelFreezePolicy . I should note that Extras maintainers only need to worry about the above once we move to using Koji as the build system. > At the same time, CVS has not been branched yet, so you should keep the > devel/ branch free of any non-bugfix changes until such time that we branch > CVS. When the branch happens has not been decided yet, we'll need to > discuss that with the rel-eng team. -- 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 j.w.r.degoede at hhs.nl Sat Apr 14 21:02:20 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 14 Apr 2007 23:02:20 +0200 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <200704140705.43381.jkeating@redhat.com> References: <200704131534.15954.jkeating@redhat.com> <200704131611.02618.jkeating@redhat.com> <46208204.4020203@hhs.nl> <200704140705.43381.jkeating@redhat.com> Message-ID: <4621415C.9040202@hhs.nl> Jesse Keating wrote: > On Saturday 14 April 2007 03:25:56 Hans de Goede wrote: >> Question 1: >> If I issue a bugfix only release to an extras package do I need todo >> anything special for it to make the Fedora 7 final spin (still assuming a >> merged Fedora 7 here) > > If merged, yes. But we are not merged now are we? So I can do any needed bugfix updates until the merge and they will get in the merged Fedora 7 when the merge happens? Then if I want todo updates for Fedora 7 after the merge I need to go through rel-eng, correct? Regards, Hans From peter at thecodergeek.com Sat Apr 14 22:09:17 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 14 Apr 2007 15:09:17 -0700 Subject: FYI: python-libtorrent Upgrade Path Is deluge Message-ID: <1176588557.12233.7.camel@tuxhugs> Hi, all. I've just committed deluge-0.5.0-2.fc7 to CVS (devel) and enqueued it to the build system. This provides an upgrade path for python-libtorrent, so things should be handled properly with an upgrade of FC-6 (which has Deluge 0.4.x) to Fedora 7/Devel (which uses the 0.5 branch of Deluge). Otherwise, python-libtorrent would be orphaned upon an upgrade (since nothing would depend on it, and it is no longer maintained). A little background for this: Deluge 0.4 made use of an external, much more general-purpose, set of python bindings to the rb_libtorrent library. However, the 0.5 branch of Deluge now implements this functionality in its own deluge_core python module (which makes use of the rb_libtorrent library, but tuned to benefit Deluge more in terms of API and feature usage). Moreover, these external bindings were written and maintained by the Deluge developers; and were meant to be used for Deluge. Although, at first I had envisioned getting the official rb_libtorrent python bindings package to replace it, but I've set it up in the spec to only Obsolete versions of python-libtorrent prior to 0.5 (which would have been thee next major EVR bump had upstream released a new major version). If we do decide to include the official bindings, these will be of the same version as the upstream tarballs (at least the current 0.11 or 0.12-RC) and so will not be "upgraded" to Deluge. If there are any related questions/comments/concerns/etc, please let me know and I will do my best to address them. Thanks. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 Sat Apr 14 22:43:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Apr 2007 18:43:17 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <4621415C.9040202@hhs.nl> References: <200704131534.15954.jkeating@redhat.com> <200704140705.43381.jkeating@redhat.com> <4621415C.9040202@hhs.nl> Message-ID: <200704141843.17568.jkeating@redhat.com> On Saturday 14 April 2007 17:02:20 Hans de Goede wrote: > But we are not merged now are we? So I can do any needed bugfix updates > until the merge and they will get in the merged Fedora 7 when the merge > happens? Then if I want todo updates for Fedora 7 after the merge I need to > go through rel-eng, correct? Correct. -- 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 Sun Apr 15 05:36:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 15 Apr 2007 07:36:24 +0200 Subject: Can upload tarball to FE CVS Message-ID: <1176615385.14629.327.camel@mccallum.corsepiu.local> Hi, I am having problems in updating/uploading a tarball to FE's CVS: # make new-sources FILES=Coin-2.4.6.tar.gz Checking : Coin-2.4.6.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-sources] Error 255 Any insights? Ralf From bugs.michael at gmx.net Sun Apr 15 08:06:13 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 15 Apr 2007 10:06:13 +0200 Subject: Can upload tarball to FE CVS In-Reply-To: <1176615385.14629.327.camel@mccallum.corsepiu.local> References: <1176615385.14629.327.camel@mccallum.corsepiu.local> Message-ID: <20070415100613.70737874.bugs.michael@gmx.net> On Sun, 15 Apr 2007 07:36:24 +0200, Ralf Corsepius wrote: > Hi, > > I am having problems in updating/uploading a tarball to FE's CVS: > > # make new-sources FILES=Coin-2.4.6.tar.gz > > Checking : Coin-2.4.6.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [new-sources] Error 255 > > Any insights? Client cert expired perhaps? See bottom of: http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq From rc040203 at freenet.de Sun Apr 15 09:12:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 15 Apr 2007 11:12:54 +0200 Subject: Can upload tarball to FE CVS In-Reply-To: <20070415100613.70737874.bugs.michael@gmx.net> References: <1176615385.14629.327.camel@mccallum.corsepiu.local> <20070415100613.70737874.bugs.michael@gmx.net> Message-ID: <1176628374.14629.331.camel@mccallum.corsepiu.local> On Sun, 2007-04-15 at 10:06 +0200, Michael Schwendt wrote: > On Sun, 15 Apr 2007 07:36:24 +0200, Ralf Corsepius wrote: > > > Hi, > > > > I am having problems in updating/uploading a tarball to FE's CVS: > > > > # make new-sources FILES=Coin-2.4.6.tar.gz > > > > Checking : Coin-2.4.6.tar.gz on > > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > > ERROR: could not check remote file status > > make: *** [new-sources] Error 255 > > > > Any insights? > > Client cert expired perhaps? See bottom of: > http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq Probably not. Retrying an hour later, without having changed anything on my part, things magically worked again :( Ralf From musuruan at gmail.com Mon Apr 16 07:44:02 2007 From: musuruan at gmail.com (Andrea Musuruane) Date: Mon, 16 Apr 2007 09:44:02 +0200 Subject: What happened to Fedora Tracker? Message-ID: <29fee02b0704160044p5a87ca66g295ee34e65d97943@mail.gmail.com> Hi, does someone know what happened to Fedora Tracker? http://fedoratracker.org/ Thanks! Bye, Andrea. From fedora at camperquake.de Mon Apr 16 12:39:11 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 16 Apr 2007 14:39:11 +0200 Subject: [GuidelinesChange] UTF8 filenames In-Reply-To: <1176315455.16445.6.camel@rousalka.dyndns.org> References: <1176224888.30783.20.camel@localhost.localdomain> <1176225463.31387.1.camel@rousalka.dyndns.org> <1176243383.30783.76.camel@localhost.localdomain> <1176244670.18654.15.camel@rousalka.dyndns.org> <1176250075.30783.91.camel@localhost.localdomain> <1176272054.24284.6.camel@rousalka.dyndns.org> <1176274523.30783.183.camel@localhost.localdomain> <32273.192.54.193.51.1176277737.squirrel@rousalka.dyndns.org> <1176299945.26832.55.camel@willson> <21947.192.54.193.51.1176306272.squirrel@rousalka.dyndns.org> <1176313877.2993.3.camel@localhost.localdomain> <1176315455.16445.6.camel@rousalka.dyndns.org> Message-ID: <20070416143911.7b7e315a@banea.int.addix.net> Hi. On Wed, 11 Apr 2007 20:17:35 +0200, Nicolas Mailhot wrote: > When you've been a technical writer you know readers, like water, > follow the path of least resistance. You want people to follow > guidelines you make clear and simple instructions, you don't waste > time waiting for the mythical will-do subject. Sorry to say so, but I do not want anyone as a fellow packager who can not be bothered to type in a simple command if the packaging docs say he/she (side note: do we have any female packagers?) should. From buildsys at fedoraproject.org Mon Apr 16 13:56:31 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 16 Apr 2007 09:56:31 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-16 Message-ID: <20070416135631.7F244152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): gnome-applet-vm FC6-updates > FC7 (0:0.1.2-1 > 0:0.1.0-2.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) hellwolf.misty AT gmail.com: wxGlade FE6 > FE7 (0:0.5-3.fc6 > 0:0.5-2.fc7) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) ---------------------------------------------------------------------- gnome-applet-vm: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.1.2-1 > 0:0.1.0-2.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) wxGlade: hellwolf.misty AT gmail.com FE6 > FE7 (0:0.5-3.fc6 > 0:0.5-2.fc7) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) From limb at jcomserv.net Mon Apr 16 14:33:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 16 Apr 2007 09:33:21 -0500 (CDT) Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <20070413165759.GD32753@neu.nirvana> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> Message-ID: <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> In the meantime, if you felt so inclined, you could request to be added as a co-maintainer and start work on it now. :) > On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: >> I've been trying to follow up on some nx bugs, and have had little >> success >> getting a hold of Richard A. Stout, zipsonic at gmail.com, the maintainer >> of >> both packages. These are the only two packages he maintains, and there >> are several untouched NEW bugs. >> >> If anyone knows how to contact him, > > The email you quote above is Rick's mail, all right. I've added him to > the Cc. If Rick is not available anymore for nx/freenx I would like to > pick these up. > >> please direct him to the AWOL bug I filed 2 weeks >> ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > > Is that's the procedure how AWOLs are probed? Just curious. > >> I hope he's out there, I use freenx every day. . . >> >> Jon Ciesla >> >> P.S. I assume since f-e-l is being closed this weekend, that AWOL >> messages >> should now go to f-m. I can edit the wiki to reflect this if this is >> correct. >> > > -- > Axel.Thimm at ATrpms.net > -- novus ordo absurdum From Axel.Thimm at ATrpms.net Mon Apr 16 15:46:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 16 Apr 2007 17:46:15 +0200 Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> Message-ID: <20070416154615.GI19042@neu.nirvana> On Mon, Apr 16, 2007 at 09:33:21AM -0500, Jon Ciesla wrote: > In the meantime, if you felt so inclined, you could request to be added as > a co-maintainer and start work on it now. :) doesn't that usually require consent from the primary maintainer who seems to be not reachable ATM? Otherwise point me to the steps I need to take, the http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership doesn't cover that afaics. > > On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: > >> I've been trying to follow up on some nx bugs, and have had little > >> success > >> getting a hold of Richard A. Stout, zipsonic at gmail.com, the maintainer > >> of > >> both packages. These are the only two packages he maintains, and there > >> are several untouched NEW bugs. > >> > >> If anyone knows how to contact him, > > > > The email you quote above is Rick's mail, all right. I've added him to > > the Cc. If Rick is not available anymore for nx/freenx I would like to > > pick these up. > > > >> please direct him to the AWOL bug I filed 2 weeks > >> ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > > > > Is that's the procedure how AWOLs are probed? Just curious. > > > >> I hope he's out there, I use freenx every day. . . > >> > >> Jon Ciesla > >> > >> P.S. I assume since f-e-l is being closed this weekend, that AWOL > >> messages > >> should now go to f-m. I can edit the wiki to reflect this if this is > >> correct. > >> > > > > > > -- 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 limb at jcomserv.net Mon Apr 16 15:51:39 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 16 Apr 2007 10:51:39 -0500 (CDT) Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <20070416154615.GI19042@neu.nirvana> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> <20070416154615.GI19042@neu.nirvana> Message-ID: <28703.65.192.24.190.1176738699.squirrel@mail.jcomserv.net> This: http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages would appear to give you the go-ahead to make corrections. I'd probably skip the co-maintainership step, and just take ownership after the completion of the AWOL process, assuming Richard doesn't respond. According to the wiki, I can make that request formally on Friday, which will then need FESCO approval, etc. > On Mon, Apr 16, 2007 at 09:33:21AM -0500, Jon Ciesla wrote: >> In the meantime, if you felt so inclined, you could request to be added >> as >> a co-maintainer and start work on it now. :) > > doesn't that usually require consent from the primary maintainer who > seems to be not reachable ATM? Otherwise point me to the steps I need > to take, the > http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership > doesn't cover that afaics. > >> > On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: >> >> I've been trying to follow up on some nx bugs, and have had little >> >> success >> >> getting a hold of Richard A. Stout, zipsonic at gmail.com, the >> maintainer >> >> of >> >> both packages. These are the only two packages he maintains, and >> there >> >> are several untouched NEW bugs. >> >> >> >> If anyone knows how to contact him, >> > >> > The email you quote above is Rick's mail, all right. I've added him to >> > the Cc. If Rick is not available anymore for nx/freenx I would like to >> > pick these up. >> > >> >> please direct him to the AWOL bug I filed 2 weeks >> >> ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 >> > >> > Is that's the procedure how AWOLs are probed? Just curious. >> > >> >> I hope he's out there, I use freenx every day. . . >> >> >> >> Jon Ciesla >> >> >> >> P.S. I assume since f-e-l is being closed this weekend, that AWOL >> >> messages >> >> should now go to f-m. I can edit the wiki to reflect this if this is >> >> correct. >> >> >> > >> > >> >> > > -- > Axel.Thimm at ATrpms.net > -- novus ordo absurdum From Axel.Thimm at ATrpms.net Mon Apr 16 16:05:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 16 Apr 2007 18:05:08 +0200 Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <28703.65.192.24.190.1176738699.squirrel@mail.jcomserv.net> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> <20070416154615.GI19042@neu.nirvana> <28703.65.192.24.190.1176738699.squirrel@mail.jcomserv.net> Message-ID: <20070416160508.GJ19042@neu.nirvana> On Mon, Apr 16, 2007 at 10:51:39AM -0500, Jon Ciesla wrote: > This: > http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages > > would appear to give you the go-ahead to make corrections. You mean the part about "experienced packagers"? While I would like to call myself that, the definition on this page doesn't fit, I'm neither a release manager, nor a sponsor, nor memebr of QA/Security SIG, nor does this package belong to any SIG. > I'd probably skip the co-maintainership step, and just take > ownership after the completion of the AWOL process, assuming Richard > doesn't respond. According to the wiki, I can make that request > formally on Friday, which will then need FESCO approval, etc. Let's do it that way then, so nobody can complain. Perhaps even Rick shows up until then, and if not, we'll have done the proper procedural steps. FWIW I have ready to submit packages with the latest bits at ATrpms. > > On Mon, Apr 16, 2007 at 09:33:21AM -0500, Jon Ciesla wrote: > >> In the meantime, if you felt so inclined, you could request to be added > >> as > >> a co-maintainer and start work on it now. :) > > > > doesn't that usually require consent from the primary maintainer who > > seems to be not reachable ATM? Otherwise point me to the steps I need > > to take, the > > http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership > > doesn't cover that afaics. > > > >> > On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: > >> >> I've been trying to follow up on some nx bugs, and have had little > >> >> success > >> >> getting a hold of Richard A. Stout, zipsonic at gmail.com, the > >> maintainer > >> >> of > >> >> both packages. These are the only two packages he maintains, and > >> there > >> >> are several untouched NEW bugs. > >> >> > >> >> If anyone knows how to contact him, > >> > > >> > The email you quote above is Rick's mail, all right. I've added him to > >> > the Cc. If Rick is not available anymore for nx/freenx I would like to > >> > pick these up. > >> > > >> >> please direct him to the AWOL bug I filed 2 weeks > >> >> ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > >> > > >> > Is that's the procedure how AWOLs are probed? Just curious. > >> > > >> >> I hope he's out there, I use freenx every day. . . > >> >> > >> >> Jon Ciesla > >> >> > >> >> P.S. I assume since f-e-l is being closed this weekend, that AWOL > >> >> messages > >> >> should now go to f-m. I can edit the wiki to reflect this if this is > >> >> correct. -- 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 limb at jcomserv.net Mon Apr 16 16:09:02 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 16 Apr 2007 11:09:02 -0500 (CDT) Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <20070416160508.GJ19042@neu.nirvana> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> <20070416154615.GI19042@neu.nirvana> <28703.65.192.24.190.1176738699.squirrel@mail.jcomserv.net> <20070416160508.GJ19042@neu.nirvana> Message-ID: <30149.65.192.24.190.1176739742.squirrel@mail.jcomserv.net> Ok. This seems rational, especially since you have much of the needed work done. Have you looked at the bug list from this BZ and assessed what your packages address and what they don't? > On Mon, Apr 16, 2007 at 10:51:39AM -0500, Jon Ciesla wrote: >> This: >> http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages >> >> would appear to give you the go-ahead to make corrections. > > You mean the part about "experienced packagers"? While I would like to > call myself that, the definition on this page doesn't fit, I'm neither > a release manager, nor a sponsor, nor memebr of QA/Security SIG, nor > does this package belong to any SIG. > >> I'd probably skip the co-maintainership step, and just take >> ownership after the completion of the AWOL process, assuming Richard >> doesn't respond. According to the wiki, I can make that request >> formally on Friday, which will then need FESCO approval, etc. > > Let's do it that way then, so nobody can complain. Perhaps even Rick > shows up until then, and if not, we'll have done the proper procedural > steps. > > FWIW I have ready to submit packages with the latest bits at ATrpms. > >> > On Mon, Apr 16, 2007 at 09:33:21AM -0500, Jon Ciesla wrote: >> >> In the meantime, if you felt so inclined, you could request to be >> added >> >> as >> >> a co-maintainer and start work on it now. :) >> > >> > doesn't that usually require consent from the primary maintainer who >> > seems to be not reachable ATM? Otherwise point me to the steps I need >> > to take, the >> > http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership >> > doesn't cover that afaics. >> > >> >> > On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: >> >> >> I've been trying to follow up on some nx bugs, and have had little >> >> >> success >> >> >> getting a hold of Richard A. Stout, zipsonic at gmail.com, the >> >> maintainer >> >> >> of >> >> >> both packages. These are the only two packages he maintains, and >> >> there >> >> >> are several untouched NEW bugs. >> >> >> >> >> >> If anyone knows how to contact him, >> >> > >> >> > The email you quote above is Rick's mail, all right. I've added him >> to >> >> > the Cc. If Rick is not available anymore for nx/freenx I would like >> to >> >> > pick these up. >> >> > >> >> >> please direct him to the AWOL bug I filed 2 weeks >> >> >> ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 >> >> > >> >> > Is that's the procedure how AWOLs are probed? Just curious. >> >> > >> >> >> I hope he's out there, I use freenx every day. . . >> >> >> >> >> >> Jon Ciesla >> >> >> >> >> >> P.S. I assume since f-e-l is being closed this weekend, that AWOL >> >> >> messages >> >> >> should now go to f-m. I can edit the wiki to reflect this if this >> is >> >> >> correct. > > -- > Axel.Thimm at ATrpms.net > -- novus ordo absurdum From Axel.Thimm at ATrpms.net Mon Apr 16 16:36:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 16 Apr 2007 18:36:16 +0200 Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <30149.65.192.24.190.1176739742.squirrel@mail.jcomserv.net> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> <20070416154615.GI19042@neu.nirvana> <28703.65.192.24.190.1176738699.squirrel@mail.jcomserv.net> <20070416160508.GJ19042@neu.nirvana> <30149.65.192.24.190.1176739742.squirrel@mail.jcomserv.net> Message-ID: <20070416163616.GM19042@neu.nirvana> On Mon, Apr 16, 2007 at 11:09:02AM -0500, Jon Ciesla wrote: > Ok. This seems rational, especially since you have much of the needed > work done. Have you looked at the bug list from this BZ and assessed what > your packages address and what they don't? I just did. Some parts like x86_64 support are already in, also some mismatching lib issues, the update requests and some crashes. What I know still exists as an issue is printing support, as this doesn't really exists in upstream either. > > On Mon, Apr 16, 2007 at 10:51:39AM -0500, Jon Ciesla wrote: > >> This: > >> http://fedoraproject.org/wiki/Extras/Policy/WhoIsAllowedToModifyWhichPackages > >> > >> would appear to give you the go-ahead to make corrections. > > > > You mean the part about "experienced packagers"? While I would like to > > call myself that, the definition on this page doesn't fit, I'm neither > > a release manager, nor a sponsor, nor memebr of QA/Security SIG, nor > > does this package belong to any SIG. > > > >> I'd probably skip the co-maintainership step, and just take > >> ownership after the completion of the AWOL process, assuming Richard > >> doesn't respond. According to the wiki, I can make that request > >> formally on Friday, which will then need FESCO approval, etc. > > > > Let's do it that way then, so nobody can complain. Perhaps even Rick > > shows up until then, and if not, we'll have done the proper procedural > > steps. > > > > FWIW I have ready to submit packages with the latest bits at ATrpms. > > > >> > On Mon, Apr 16, 2007 at 09:33:21AM -0500, Jon Ciesla wrote: > >> >> In the meantime, if you felt so inclined, you could request to be > >> added > >> >> as > >> >> a co-maintainer and start work on it now. :) > >> > > >> > doesn't that usually require consent from the primary maintainer who > >> > seems to be not reachable ATM? Otherwise point me to the steps I need > >> > to take, the > >> > http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership > >> > doesn't cover that afaics. > >> > > >> >> > On Fri, Apr 13, 2007 at 09:24:26AM -0500, Jon Ciesla wrote: > >> >> >> I've been trying to follow up on some nx bugs, and have had little > >> >> >> success > >> >> >> getting a hold of Richard A. Stout, zipsonic at gmail.com, the > >> >> maintainer > >> >> >> of > >> >> >> both packages. These are the only two packages he maintains, and > >> >> there > >> >> >> are several untouched NEW bugs. > >> >> >> > >> >> >> If anyone knows how to contact him, > >> >> > > >> >> > The email you quote above is Rick's mail, all right. I've added him > >> to > >> >> > the Cc. If Rick is not available anymore for nx/freenx I would like > >> to > >> >> > pick these up. > >> >> > > >> >> >> please direct him to the AWOL bug I filed 2 weeks > >> >> >> ago:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > >> >> > > >> >> > Is that's the procedure how AWOLs are probed? Just curious. > >> >> > > >> >> >> I hope he's out there, I use freenx every day. . . > >> >> >> > >> >> >> Jon Ciesla > >> >> >> > >> >> >> P.S. I assume since f-e-l is being closed this weekend, that AWOL > >> >> >> messages > >> >> >> should now go to f-m. I can edit the wiki to reflect this if this > >> is > >> >> >> correct. > > > > > > -- 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 notting at redhat.com Mon Apr 16 17:57:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 16 Apr 2007 13:57:22 -0400 Subject: How to load a kernel module automatically? In-Reply-To: <4620AE40.5030702@gmail.gom> References: <460F9046.2020405@gmail.gom> <200704012110.32881.ville.skytta@iki.fi> <46138AFE.50909@gmail.gom> <200704041505.00482.ville.skytta@iki.fi> <461FD580.60503@gmail.gom> <20070413191906.GA7462@nostromo.devel.redhat.com> <461FD8F0.3010108@gmail.gom> <20070413201316.GB4590@nostromo.devel.redhat.com> <4620AE40.5030702@gmail.gom> Message-ID: <20070416175722.GF5800@nostromo.devel.redhat.com> Julian Sikorski (belegdol at gmail.com) said: > > If you want to do it directly in udev, instead, something like: > > > > BUS=="usb", SYSFS{idProduct}=="0483", SYSFS{idVendor}=="2016", RUN+="/sbin/modprobe uinput" > > > > in a /etc/udev/rules.d rules file should work. > > You think it a better idea than /etc/sysconfig/modules scriptlet? If so, > I will switch to this solution. Yes, because it will tie it to the particular hardware piece, rather than anyone who installs thinkfinger. Please test it to make sure I didn't botch the udev syntax, though :) Bill From jspaleta at gmail.com Mon Apr 16 19:44:57 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 16 Apr 2007 11:44:57 -0800 Subject: Question on how to handled "GPL with exceptions" in a package review. Message-ID: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> Good Morning campers, I've been working on the review of pigment and I had a question concerning whether I need to ask for a legal review of the license. Its GPL with an additional exception clause. Now personally, I've no problem with the additional clause but I aint no lawyer'n type monkey so take my opinion with a grain of salt. This is the first time I've come across a GPL with additional exceptions license as a reviewer so I want to tread carefully. Do additional exceptions tacked on to the GPL require a legal review or is this a best judgement situation? -jef From tcallawa at redhat.com Mon Apr 16 19:46:30 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 16 Apr 2007 14:46:30 -0500 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> Message-ID: <1176752790.3970.360.camel@localhost.localdomain> On Mon, 2007-04-16 at 11:44 -0800, Jeff Spaleta wrote: > Good Morning campers, > > I've been working on the review of pigment and I had a question > concerning whether I need > to ask for a legal review of the license. Its GPL with an additional > exception clause. Now personally, I've no problem with the additional > clause but I aint no lawyer'n type monkey so take my opinion with a > grain of salt. This is the first time I've come across a GPL with > additional exceptions license as a reviewer so I want to tread > carefully. > > Do additional exceptions tacked on to the GPL require a legal review > or is this a best judgement situation? Probably the former. Please post the license text, or throw the bugzilla number at me. ~spot From limb at jcomserv.net Mon Apr 16 19:46:11 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 16 Apr 2007 14:46:11 -0500 (CDT) Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> Message-ID: <51315.65.192.24.190.1176752771.squirrel@mail.jcomserv.net> IANAL, SIPCHYVM, but out of curiosity, what's the clause? > Good Morning campers, > > I've been working on the review of pigment and I had a question > concerning whether I need > to ask for a legal review of the license. Its GPL with an additional > exception clause. Now personally, I've no problem with the additional > clause but I aint no lawyer'n type monkey so take my opinion with a > grain of salt. This is the first time I've come across a GPL with > additional exceptions license as a reviewer so I want to tread > carefully. > > Do additional exceptions tacked on to the GPL require a legal review > or is this a best judgement situation? > > -jef > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From sundaram at fedoraproject.org Mon Apr 16 19:56:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Apr 2007 01:26:36 +0530 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> Message-ID: <4623D4F4.4050305@fedoraproject.org> Jeff Spaleta wrote: > Good Morning campers, > > I've been working on the review of pigment and I had a question > concerning whether I need > to ask for a legal review of the license. Its GPL with an additional > exception clause. Now personally, I've no problem with the additional > clause but I aint no lawyer'n type monkey so take my opinion with a > grain of salt. This is the first time I've come across a GPL with > additional exceptions license as a reviewer so I want to tread > carefully. > > Do additional exceptions tacked on to the GPL require a legal review > or is this a best judgement situation? The rule of thumb when dealing with GPL exceptions is to ask yourself this question: Does it add restrictions or does it relax it? Allowing more than what the GPL license would otherwise do is ok. For example, a exception to allow a GPL'ed library to link to OpenSSL. A exception that adds restrictions on top is not ok. For example, you may not use this application in a commercial way. The GPL exception on this pigment review https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233597 seem ok to me. Rahul From bnocera at redhat.com Mon Apr 16 21:04:00 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 16 Apr 2007 22:04:00 +0100 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <1176752790.3970.360.camel@localhost.localdomain> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> Message-ID: <1176757440.30063.19.camel@cookie.hadess.net> On Mon, 2007-04-16 at 14:46 -0500, Tom "spot" Callaway wrote: > On Mon, 2007-04-16 at 11:44 -0800, Jeff Spaleta wrote: > Probably the former. Please post the license text, or throw the bugzilla > number at me. I believe it's the "allow GStreamer proprietary codecs to run in the same address space as this" exception. Totem has the same one, and hopefully Rhythmbox will soon. It allows people to buy codecs from Fluendo for playback. From jspaleta at gmail.com Tue Apr 17 00:41:41 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 16 Apr 2007 16:41:41 -0800 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <1176752790.3970.360.camel@localhost.localdomain> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> Message-ID: <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> On 4/16/07, Tom spot Callaway wrote: > Probably the former. Please post the license text, or throw the bugzilla > number at me. pigment ticket: 233597 elisa ticket: 233598 both have the same additional clause. The text of the additional clause is: Fluendo hereby grants permission for anyone under a valid license distributing Fluendo's non-GPL compatible GStreamer plugins to distribute and use them together with GStreamer and Elisa. This permission is above and beyond the permissions granted by the GPL license by which Elisa is covered. If you modify this code, you may extend this permission to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Like I said this looks fine to me, but I hadn't run across an exceptions situation yet in a review. -jef From blizzard at redhat.com Tue Apr 17 02:11:44 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 16 Apr 2007 22:11:44 -0400 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> Message-ID: <1176775904.15076.4.camel@localhost.localdomain> On Mon, 2007-04-16 at 16:41 -0800, Jeff Spaleta wrote: > On 4/16/07, Tom spot Callaway wrote: > > Probably the former. Please post the license text, or throw the bugzilla > > number at me. > > pigment ticket: 233597 > elisa ticket: 233598 > > both have the same additional clause. The text of the additional clause is: > > Fluendo hereby grants permission for anyone under a valid license distributing > Fluendo's non-GPL compatible GStreamer plugins to distribute and use them > together with GStreamer and Elisa. This permission is above and beyond the > permissions granted by the GPL license by which Elisa is covered. If you > modify this code, you may extend this permission to your version of the code, > but you are not obligated to do so. If you do not wish to do so, delete this > exception statement from your version. > > > Like I said this looks fine to me, but I hadn't run across an > exceptions situation yet in a review. Yeah, it's an extension. It's very similar to the verbage that we used in the Fedora Directory Server. What surprises me is that the grant only applies to Fluendo's plugins and not anyone to plugins that are created by anyone else. --Chris From buildsys at fedoraproject.org Tue Apr 17 02:36:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 16 Apr 2007 22:36:45 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-16 Message-ID: <20070417023645.A8EB6152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): gnome-applet-vm FC6-updates > FC7 (0:0.1.2-1 > 0:0.1.0-2.fc7) enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) ---------------------------------------------------------------------- gnome-applet-vm: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:0.1.2-1 > 0:0.1.0-2.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) From rc040203 at freenet.de Tue Apr 17 04:17:45 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 17 Apr 2007 06:17:45 +0200 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <4623D4F4.4050305@fedoraproject.org> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <4623D4F4.4050305@fedoraproject.org> Message-ID: <1176783465.31298.148.camel@mccallum.corsepiu.local> On Tue, 2007-04-17 at 01:26 +0530, Rahul Sundaram wrote: > Jeff Spaleta wrote: > > Good Morning campers, > > > > I've been working on the review of pigment and I had a question > > concerning whether I need > > to ask for a legal review of the license. Its GPL with an additional > > exception clause. Now personally, I've no problem with the additional > > clause but I aint no lawyer'n type monkey so take my opinion with a > > grain of salt. This is the first time I've come across a GPL with > > additional exceptions license as a reviewer so I want to tread > > carefully. > > > > Do additional exceptions tacked on to the GPL require a legal review > > or is this a best judgement situation? > Allowing more than what the GPL license would otherwise do is ok. > For example, a exception to allow a GPL'ed library to link to OpenSSL. A real world example where the FSF itself applies such a "GPL w/ exceptions" is the license of libstdc++. > The GPL exception on this pigment review > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233597 seem ok to me. ACK. Ralf From tgl at redhat.com Tue Apr 17 04:58:10 2007 From: tgl at redhat.com (Tom Lane) Date: Tue, 17 Apr 2007 00:58:10 -0400 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <1176775904.15076.4.camel@localhost.localdomain> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> <1176775904.15076.4.camel@localhost.localdomain> Message-ID: <15073.1176785890@sss.pgh.pa.us> Christopher Blizzard writes: > On Mon, 2007-04-16 at 16:41 -0800, Jeff Spaleta wrote: >> both have the same additional clause. The text of the additional clause is: >> >> Fluendo hereby grants permission for anyone under a valid license distributing >> Fluendo's non-GPL compatible GStreamer plugins to distribute and use them >> together with GStreamer and Elisa. This permission is above and beyond the >> permissions granted by the GPL license by which Elisa is covered. If you >> modify this code, you may extend this permission to your version of the code, >> but you are not obligated to do so. If you do not wish to do so, delete this >> exception statement from your version. > What surprises me is that the grant only applies to Fluendo's plugins > and not anyone to plugins that are created by anyone else. Maybe I'm missing something, but it seems to me that this is really a relaxation of the license for the plugins, and not so much for either GStreamer or Elisa. So naturally it falls to Fluendo (owner of the plugins) to do that. For a hypothetical non-GPL plugin X, it would be up to X's owner to say "yeah, you can distribute this with GStreamer all you want, even though it's not GPL". regards, tom lane From fedora at leemhuis.info Tue Apr 17 04:58:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 06:58:52 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46244EE2.5060002@redhat.com> References: <46244EE2.5060002@redhat.com> Message-ID: <4624540C.7010109@leemhuis.info> > 1. In the future we should consider a mass rebuild of all packages > around, but no later than test2 Hmmm, this was discussed in depth at the end of this thread: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html Some people would like to see a mass rebuild, some others are against it. I'm one of those against it. Reasons: - Seems we have quite some users in country were internet bandwidth is unreliable and costly. If we mass-rebuild everything each time those users have to download a lot of new stuff where nothing changed besides the release. that makes Fedora harder to use for them. - the update process gets much longer for each and everyone of us if each package has to be downloaded and updated. - the packages out in the wild are tested and known to work. Rebuild packages have to proof again that everything is fine (which should be the case most of the time, but in rare cases isn't) IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth the trouble we create for our users. I think a mass rebuild now and then when the toolchain (things like gcc or other crucial stuff like rpm, python,...) changed massively (round about probably every second or third release cycle) is more then enough. CU thl From davej at redhat.com Tue Apr 17 05:48:14 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 17 Apr 2007 01:48:14 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624540C.7010109@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> Message-ID: <20070417054814.GA11690@redhat.com> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > 1. In the future we should consider a mass rebuild of all packages > > around, but no later than test2 > > Hmmm, this was discussed in depth at the end of this thread: > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html > Some people would like to see a mass rebuild, some others are against it. > > I'm one of those against it. Reasons: > - Seems we have quite some users in country were internet bandwidth is > unreliable and costly. If we mass-rebuild everything each time those > users have to download a lot of new stuff where nothing changed besides > the release. that makes Fedora harder to use for them. And these users are running rawhide ? > - the update process gets much longer for each and everyone of us if > each package has to be downloaded and updated. > - the packages out in the wild are tested and known to work. Rebuild > packages have to proof again that everything is fine (which should be > the case most of the time, but in rare cases isn't) > > IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth > the trouble we create for our users. I think a mass rebuild now and then > when the toolchain (things like gcc or other crucial stuff like rpm, > python,...) changed massively (round about probably every second or > third release cycle) is more then enough. Yeah, I'll agree with that. Off the top of my head, I can come up with three scenarios where rebuilds make sense. - Considerable bugfixes which fix up bad code generation. - new/enhanced features (such as more FORTIFY_SOURCE improvements) - new optimisations (We could even narrow the scope on this one to rebuild just packages that would show a notable difference. Ie, don't bother rebuilding fileutils, but do rebuild say, bzip2). Taking a look at the packages in my f7 mirror, I spot 52 packages that still have a .fc6 tag, none of which look particularly "omg, we have to rebuild this". There are also 713 with no %{dist} tag which include some which we definitly have rebuilt, so it's harder to figure out which of those got updated and which didn't. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Tue Apr 17 06:22:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 08:22:44 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417054814.GA11690@redhat.com> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> Message-ID: <462467B4.8000608@leemhuis.info> On 17.04.2007 07:48, Dave Jones wrote: > On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > > 1. In the future we should consider a mass rebuild of all packages > > > around, but no later than test2 > > Hmmm, this was discussed in depth at the end of this thread: > > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html > > Some people would like to see a mass rebuild, some others are against it. > > > > I'm one of those against it. Reasons: > > - Seems we have quite some users in country were internet bandwidth is > > unreliable and costly. If we mass-rebuild everything each time those > > users have to download a lot of new stuff where nothing changed besides > > the release. that makes Fedora harder to use for them. > And these users are running rawhide ? Probably not, but they will have to download and install the new packages that got build during the mass-rebuild when they do the Fedora (x) -> Fedora (x+1 or x+2) update. Currently packages where nothing changed in between simply stay installed and no action is needed. > > - the update process gets much longer for each and everyone of us if > > each package has to be downloaded and updated. > > - the packages out in the wild are tested and known to work. Rebuild > > packages have to proof again that everything is fine (which should be > > the case most of the time, but in rare cases isn't) > > > > IOW: The benefits of a mass rebuild *each* devel cycle is IMHO not worth > > the trouble we create for our users. I think a mass rebuild now and then > > when the toolchain (things like gcc or other crucial stuff like rpm, > > python,...) changed massively (round about probably every second or > > third release cycle) is more then enough. > > Yeah, I'll agree with that. > Off the top of my head, I can come up with three scenarios where > rebuilds make sense. > > - Considerable bugfixes which fix up bad code generation. > - new/enhanced features (such as more FORTIFY_SOURCE improvements) > - new optimisations > (We could even narrow the scope on this one to rebuild just > packages that would show a notable difference. Ie, don't > bother rebuilding fileutils, but do rebuild say, bzip2). +1 > Taking a look at the packages in my f7 mirror, I spot 52 packages > that still have a .fc6 tag, none of which look particularly > "omg, we have to rebuild this". There are also 713 with no %{dist} tag > which include some which we definitly have rebuilt, so it's harder > to figure out which of those got updated and which didn't. Some numbers: $ fc6release=$(date -d "24 Oct 2006" +%s); sudo repoquery --repoid=development-source --repoid=extras-development-source --archlist="src" -qa --qf '%{buildtime} %{name}' | sort | while read date name; do [[ ${date} < ${fc6release} ]] && echo ${date} ${name} || break ; done | wc -l 1206 $ sudo repoquery --repoid=development-source --repoid=extras-development-source --archlist="src" -qa --qf '%{buildtime} %{name}' | wc -l 4073 $ echo $((4073-1206)) 2867 IOW: 1206 out of 4073 source packages were not rebuild in devel (both core and extras) between release of FC6 and now. CU thl From Axel.Thimm at ATrpms.net Tue Apr 17 07:42:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 09:42:04 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462467B4.8000608@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> Message-ID: <20070417074204.GF5695@neu.nirvana> On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote: > On 17.04.2007 07:48, Dave Jones wrote: > >On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > > > 1. In the future we should consider a mass rebuild of all packages > > > > around, but no later than test2 > >Taking a look at the packages in my f7 mirror, I spot 52 packages > >that still have a .fc6 tag, none of which look particularly > >"omg, we have to rebuild this". There are also 713 with no %{dist} tag > >which include some which we definitly have rebuilt, so it's harder > >to figure out which of those got updated and which didn't. > > Some numbers: > $ echo $((4073-1206)) > 2867 > > IOW: 1206 out of 4073 source packages were not rebuild in devel (both > core and extras) between release of FC6 and now. But that's by choice and now what the usual Fedora policy was until now. Here is the historical data, that shows that we've been doing effectively full rebuilds ever until now. On Tue, Apr 10, 2007 at 03:33:29PM +0200, Axel Thimm wrote: > 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. -- 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 17 08:13:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 10:13:11 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624540C.7010109@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> Message-ID: <20070417081311.GG5695@neu.nirvana> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > > > 1. In the future we should consider a mass rebuild of all packages > >around, but no later than test2 > > Hmmm, this was discussed in depth at the end of this thread: > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00017.html > Some people would like to see a mass rebuild, some others are against it. > > I'm one of those against it. Reasons: I'm one of those for it. > - Seems we have quite some users in country were internet bandwidth is > unreliable and costly. If we mass-rebuild everything each time those > users have to download a lot of new stuff where nothing changed besides > the release. that makes Fedora harder to use for them. The big players that are always on the user's choicelist are being rebuilt almost by definition. The savings are therefore marginal at best. > - the update process gets much longer for each and everyone of us if > each package has to be downloaded and updated. > - the packages out in the wild are tested and known to work. Rebuild > packages have to proof again that everything is fine (which should be > the case most of the time, but in rare cases isn't) That's a contradiction: Either the packages are stable and will survive a rebuild, or they are fragile enough to break apart if they are rebuilt in the current environment. Furthermore the testing these packages have received was on another release offering a different build and run-time environment, so they may not be as stable or tested as you think they are. The dangers of letting packages go to seed are the following: o non deterministic package rebuilds: It is not guaranteed that some package will rebuild and function the same for the current release (we may have automated rebuild facilities, but no one tests runtime behaviour), a simple rebuild may unearth that the package needs further attention (in fact that is Thorsten's argument to not rebuild, but the attention will be needed, the question is when to spend the time on it, see below) o slow security responses: A one-line fix may result to a package breaking due to the above. This means that security issues may start shipping broken packages out, or may require more time in QA to ensure that an ancient-not-rebuilt package really properly works. o The choice of what to rebuild or not requires more developer time than fixing broken rebuilds: Currently some heuristics were uses to cherry-pick what to rebuild. This requires a careful examination that if doen properly consumes as much or more developer time than to fix any broken rebuilds. If not done careful, then some dependencies will be missed. For example the current upgrade sees the following changes in the buildtools FC6 F7 gcc 4.1.1-30 4.1.2-8 glibc 2.5-3 2.5.90-20 binutils 2.17.50.0.3-6 2.17.50.0.12-3 Perhaps the gcc or binutils changes are not that big, but the glibc ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking the API (the glibc-headers) gives: 41 files changed, 297 insertions(+), 220 deletions(-) Other examples are packages (like bridge-utils) being built against kernel-headers. F7 is now shipping a bridge-utils that was built agains 2.6.18 kernel headers at the very beginning of the FC6 cycle. The questions that come up are: Did anyone check whether the bridging interface of the kernel changed between 2.6.18-21? Were any interfaces deprecated? Will bridge-utils work on F7, if not will a rebuild suffice? I've picked bridge-utils as an example as it was the first package that looked suspicious when I looked at an alphabetical list, that doesn't mean that bridge-utils is now broken. Still the questions raised are valid for any package depending on kernel-headers. o Moving bugs from development cycle to maintenance cycle: Effectively the argument for not rebuilding during development time and breaking N fragile packages means that once these N broken packages are spotted after the release they will need the developer's attention just the same. We are only moving the bugs from the devlopment cycle to mainenance. Do we really want that? From a technical and *marketing* POV we don't. It is better to ship a good release from the start, than to stumble over rebuild bugs over and over again, and that includes both deelopers and now users. And from a *business* POV the resources that are spent are the same, someone must fix the packages. So let's do it during the development cycle instead of during maintenance where the users will feel like guinea pigs. In a nutshell: There are no significant savings in user downloads, and there are no savings in developer resources when not rebuilding packages to match the upcoming release environment. But there is bad publicity if packages will break after the release and this could had been prevented with a simple mass rebuild during devlopment time instead of outsourcing this to the maintenance cycle. -- 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 Tue Apr 17 08:14:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 10:14:15 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417074204.GF5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> Message-ID: <462481D7.5050802@leemhuis.info> On 17.04.2007 09:42, Axel Thimm wrote: > On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote: >> On 17.04.2007 07:48, Dave Jones wrote: >>> On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: >>>>> 1. In the future we should consider a mass rebuild of all packages >>>>> around, but no later than test2 >>> Taking a look at the packages in my f7 mirror, I spot 52 packages >>> that still have a .fc6 tag, none of which look particularly >>> "omg, we have to rebuild this". There are also 713 with no %{dist} tag >>> which include some which we definitly have rebuilt, so it's harder >>> to figure out which of those got updated and which didn't. >> Some numbers: >> $ echo $((4073-1206)) >> 2867 >> IOW: 1206 out of 4073 source packages were not rebuild in devel (both >> core and extras) between release of FC6 and now. > > But that's by choice and now what the usual Fedora policy was until > now. There is no "policy" afaik. The maintainer simply decided what to do if no mass-rebuild was announced. There were for example mass rebuilds performed in FC6 and FE6. > Here is the historical data, that shows that we've been doing > effectively full rebuilds ever until now. [...] Just a heads up for the readers (as it's not obvious in the first sight): The data from Axel is for Core only afaics, my data included Extras. CU thl From Axel.Thimm at ATrpms.net Tue Apr 17 08:35:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 10:35:15 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <462481D7.5050802@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> Message-ID: <20070417083515.GH5695@neu.nirvana> On Tue, Apr 17, 2007 at 10:14:15AM +0200, Thorsten Leemhuis wrote: > On 17.04.2007 09:42, Axel Thimm wrote: > >On Tue, Apr 17, 2007 at 08:22:44AM +0200, Thorsten Leemhuis wrote: > >>On 17.04.2007 07:48, Dave Jones wrote: > >>>On Tue, Apr 17, 2007 at 06:58:52AM +0200, Thorsten Leemhuis wrote: > >>>>> 1. In the future we should consider a mass rebuild of all packages > >>>>>around, but no later than test2 > >>>Taking a look at the packages in my f7 mirror, I spot 52 packages > >>>that still have a .fc6 tag, none of which look particularly > >>>"omg, we have to rebuild this". There are also 713 with no %{dist} tag > >>>which include some which we definitly have rebuilt, so it's harder > >>>to figure out which of those got updated and which didn't. > >>Some numbers: > >>$ echo $((4073-1206)) > >>2867 > >>IOW: 1206 out of 4073 source packages were not rebuild in devel (both > >>core and extras) between release of FC6 and now. > > > >But that's by choice and now what the usual Fedora policy was until > >now. > > There is no "policy" afaik. The maintainer simply decided what to do if > no mass-rebuild was announced. There were for example mass rebuilds > performed in FC6 and FE6. Well, let's not play with wording, the numbers speak for themselves: In the history of Fedora until F7 both FC and FE did effectively full rebuilds. > >Here is the historical data, that shows that we've been doing > >effectively full rebuilds ever until now. > On Tue, Apr 10, 2007 at 03:33:29PM +0200, Axel Thimm wrote: > > 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 a heads up for the readers (as it's not obvious in the first > sight): The data from Axel is for Core only afaics, my data included Extras. Well, I can include Extras, too, the data above was from a mail to Jesse when it was about Core. For Extras the numbers are far more striking, here is a common table including the FC data: FC FE 1 100% - 2 99.7% - 3 100% 100% 4 96.6% 99.4% 5 99.991% 99.0% 6 95% 99.4% 7 80% 62% So Extras was even closer to a complete rebuilds, leaving out 0.6% to 1% of packages at most until FC6 inclusive. Since FE has more packages the merged full repo will look more like FE's rebuild rates. But since the CD/DVD spins are made mostly out of former Core bits the actual rate of bugs found due to non-rebuilds will be closer to FC's. That's a bit comforting, since FC has seen some more rebuilds. We are on new territory with F7, both on the FC and FE side. Let's prey for the best. -- 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 Tue Apr 17 09:10:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 11:10:18 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417083515.GH5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> Message-ID: <46248EFA.40304@leemhuis.info> On 17.04.2007 10:35, Axel Thimm wrote: > [...] > Well, I can include Extras, too, the data above was from a mail to > Jesse when it was about Core. For Extras the numbers are far more > striking, here is a common table including the FC data [...] Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6] were released? Otherwise your numbers are IMHO totally misleading, as they show what got rebuild between release of FC[3-6] and *today*. CU thl From Axel.Thimm at ATrpms.net Tue Apr 17 09:32:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 11:32:15 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46248EFA.40304@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> Message-ID: <20070417093215.GM5695@neu.nirvana> On Tue, Apr 17, 2007 at 11:10:18AM +0200, Thorsten Leemhuis wrote: > On 17.04.2007 10:35, Axel Thimm wrote: > >[...] > >Well, I can include Extras, too, the data above was from a mail to > >Jesse when it was about Core. For Extras the numbers are far more > >striking, here is a common table including the FC data [...] > > Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6] > were released? No, do you? > Otherwise your numbers are IMHO totally misleading, as they show > what got rebuild between release of FC[3-6] and *today*. No, they compare the latest state of FE and the latest state of FE. For FE5 and FE6 for example it compares the latest state as of today. For FE4 and FE5 it compares FE4's EOL date (~FC6) and today. So there is no time discrepancy as you assume. And it comes as no suprise since as we all should know FE was always doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% were forgotten in the process. Perhaps someone did a rebuild with the same EVR - we didn't catch these in the old days. -- 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 nicolas.mailhot at laposte.net Tue Apr 17 10:19:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 17 Apr 2007 12:19:10 +0200 (CEST) Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <1176775904.15076.4.camel@localhost.localdomain> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> <1176775904.15076.4.camel@localhost.localdomain> Message-ID: <22069.192.54.193.52.1176805150.squirrel@rousalka.dyndns.org> Le Mar 17 avril 2007 04:11, Christopher Blizzard a ?crit : > > What surprises me is that the grant only applies to Fluendo's plugins > and not anyone to plugins that are created by anyone else. Fluendo of course knows it won't use its pluggins own to abuse the license of the core code. If they granted a generic plugin clause you bet someone would try to close modifications to core code, calling it a "pluggin" -- Nicolas Mailhot From fedora at leemhuis.info Tue Apr 17 10:19:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 12:19:21 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417093215.GM5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> Message-ID: <46249F29.9090003@leemhuis.info> On 17.04.2007 11:32, Axel Thimm wrote: > On Tue, Apr 17, 2007 at 11:10:18AM +0200, Thorsten Leemhuis wrote: >> On 17.04.2007 10:35, Axel Thimm wrote: >>> [...] >>> Well, I can include Extras, too, the data above was from a mail to >>> Jesse when it was about Core. For Extras the numbers are far more >>> striking, here is a common table including the FC data [...] >> Hmmm, do you sill have a tree of FE[3-6] how it looked like when FC[3-6] >> were released? > No, do you? No, sorry, I don't have any local Extras trees at all. >> Otherwise your numbers are IMHO totally misleading, as they show >> what got rebuild between release of FC[3-6] and *today*. > No, they compare the latest state of FE and the latest state of > FE. For FE5 and FE6 for example it compares the latest state as > of today. For FE4 and FE5 it compares FE4's EOL date (~FC6) and > today. So there is no time discrepancy as you assume. Assume package foo-1.0-1.noarch was in FE5 and devel. The FE6 got branched, so foo was not rebuild during that devel cycle (this is thus a example of a package we are up to: one that didn't get rebuild during a devel cycle). Some weeks later foo got a update to foo-1.1-1.noarch; it got build in both FE5, FE6 and FE-devel. Got a bugfix with foo-1.1-2.noarch; the old one foo-1.0-1.noarch gets deleted from the tree then, as we only ship the two latest versions. So how can your scripts detect now that foo-1.0-1.noarch wasn't rebuild during the devel-period FE5->FE6 by looking at todays repos? > And it comes as no suprise since as we all should know FE was always > doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% > were forgotten in the process. Perhaps someone did a rebuild with the > same EVR - we didn't catch these in the old days. We never did full rebuilds. Data-packages never had to be rebuild. Noarch packages (python, perl) did not have to be rebuild during those mass rebuilds either iirc (but we adviced to do it when preparing FE6 iirc). CU thl From nicolas.mailhot at laposte.net Tue Apr 17 10:42:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 17 Apr 2007 12:42:45 +0200 (CEST) Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <15073.1176785890@sss.pgh.pa.us> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> <1176775904.15076.4.camel@localhost.localdomain> <15073.1176785890@sss.pgh.pa.us> Message-ID: <27712.192.54.193.52.1176806565.squirrel@rousalka.dyndns.org> Le Mar 17 avril 2007 06:58, Tom Lane a ?crit : > For a hypothetical non-GPL plugin X, it would > be up to X's owner to say "yeah, you can distribute this with GStreamer > all you want, even though it's not GPL". Wrong. the hypothetical non-GPL plugin owner would have to prove even though it's digging deeply within gstreamer insternals it's not a gstreamer derivative and the GPL does not apply to the pluggin code What fluendo did is grant itself the permission to release and have distributed derivative code not bound by the gstreamer license (because FLOSS obligations are incompatible with the video patent regimes out there) -- Nicolas Mailhot From jakub at redhat.com Tue Apr 17 11:00:39 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 17 Apr 2007 07:00:39 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417081311.GG5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417081311.GG5695@neu.nirvana> Message-ID: <20070417110039.GK355@devserv.devel.redhat.com> On Tue, Apr 17, 2007 at 10:13:11AM +0200, Axel Thimm wrote: > o The choice of what to rebuild or not requires more developer time > than fixing broken rebuilds: Currently some heuristics were uses to > cherry-pick what to rebuild. This requires a careful examination > that if doen properly consumes as much or more developer time than > to fix any broken rebuilds. If not done careful, then some > dependencies will be missed. For example the current upgrade sees > the following changes in the buildtools > > FC6 F7 > gcc 4.1.1-30 4.1.2-8 > glibc 2.5-3 2.5.90-20 > binutils 2.17.50.0.3-6 2.17.50.0.12-3 > > Perhaps the gcc or binutils changes are not that big, but the glibc > ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking > the API (the glibc-headers) gives: > > 41 files changed, 297 insertions(+), 220 deletions(-) Even the glibc changes in F7 are mostly glibc internal changes, bugfixes and addition of a few new symbols (epoll_wait, sync_file_range, strerror_l, __sched_cpucount) and only on PPC a new version for existing symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc changes necessitate a mass rebuild (and I'm not aware of any huge changes in redhat-rpm-config either) at this time and that's why F7 rebuild status is so low. GCC 4.2 has been stagnating for 6 months now and we have several important things backported anyway in GCC 4.1.x-RH (OpenMP, visibility stuff, Java stack, numerous Fortran improvements, many bugfixes, ...). If gcc, binutils or glibc changes substantially in say F8, we'll of course need to do a mass rebuild. I'd note that sometimes it makes sense to rebuild all packages, including noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config etc. changes that affect all packages. Jakub From Axel.Thimm at ATrpms.net Tue Apr 17 11:05:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 13:05:48 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <46249F29.9090003@leemhuis.info> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> <46249F29.9090003@leemhuis.info> Message-ID: <20070417110548.GN5695@neu.nirvana> On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote: > >And it comes as no suprise since as we all should know FE was always > >doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% > >were forgotten in the process. Perhaps someone did a rebuild with the > >same EVR - we didn't catch these in the old days. > > We never did full rebuilds. Data-packages never had to be rebuild. OK, that accounts for the 0.6-1% then. As you know I'm not advocating rebuilding stuff like firmware that are known to be content-invariant over time. -- 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 Tue Apr 17 11:31:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Apr 2007 13:31:49 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417110548.GN5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> <46249F29.9090003@leemhuis.info> <20070417110548.GN5695@neu.nirvana> Message-ID: <4624B025.10205@leemhuis.info> On 17.04.2007 13:05, Axel Thimm wrote: > On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote: >>> And it comes as no suprise since as we all should know FE was always >>> doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% >>> were forgotten in the process. Perhaps someone did a rebuild with the >>> same EVR - we didn't catch these in the old days. >> We never did full rebuilds. Data-packages never had to be rebuild. > OK, that accounts for the 0.6-1% then. [...] Well, you carefully didn't reply to the part where I explained that you can't get to a proper number "how many packages weren't rebuild in the devel cycle FE5 -> FE6" by looking at todays repos. So the 0.6-1% are FUD in my eyes. I don't have hard numbers either -- but from memory I'd say we didn't rebuild round about 1/3 of the packages in the FE mass rebuild for FC6. Some of those not rebuild received updates earlier or later in the devel cycle. So if I should guess I'd say the number of packages that didn't get rebuild between FE5 and FE6 was somewhere between 7.5 and 25 percent. Maybe Ville has more data, he did a lot of work back then for the mass rebuild. CU thl /me will try to resist from this thread now, this doesn't lead to anything From Axel.Thimm at ATrpms.net Tue Apr 17 11:56:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 13:56:51 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417110039.GK355@devserv.devel.redhat.com> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417081311.GG5695@neu.nirvana> <20070417110039.GK355@devserv.devel.redhat.com> Message-ID: <20070417115651.GO5695@neu.nirvana> On Tue, Apr 17, 2007 at 07:00:39AM -0400, Jakub Jelinek wrote: > On Tue, Apr 17, 2007 at 10:13:11AM +0200, Axel Thimm wrote: > > o The choice of what to rebuild or not requires more developer time > > than fixing broken rebuilds: Currently some heuristics were uses to > > cherry-pick what to rebuild. This requires a careful examination > > that if doen properly consumes as much or more developer time than > > to fix any broken rebuilds. If not done careful, then some > > dependencies will be missed. For example the current upgrade sees > > the following changes in the buildtools > > > > FC6 F7 > > gcc 4.1.1-30 4.1.2-8 > > glibc 2.5-3 2.5.90-20 > > binutils 2.17.50.0.3-6 2.17.50.0.12-3 > > > > Perhaps the gcc or binutils changes are not that big, but the glibc > > ones seem to be, e.g. 2.5.90 is the prequel to 2.6 and just checking > > the API (the glibc-headers) gives: > > > > 41 files changed, 297 insertions(+), 220 deletions(-) > > Even the glibc changes in F7 are mostly glibc internal changes, bugfixes > and addition of a few new symbols (epoll_wait, sync_file_range, > strerror_l, __sched_cpucount) and only on PPC a new version for existing > symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc > changes necessitate a mass rebuild (and I'm not aware of any huge changes > in redhat-rpm-config either) at this time and that's why F7 rebuild status > is so low. GCC 4.2 has been stagnating for 6 months now and we have > several important things backported anyway in GCC 4.1.x-RH (OpenMP, > visibility stuff, Java stack, numerous Fortran improvements, many bugfixes, > ...). When did these backports happen between 4.1.1-30 and 4.1.2-8 or earlier? > If gcc, binutils or glibc changes substantially in say F8, we'll > of course need to do a mass rebuild. gcc should finally have made it to 4.2 by then. > I'd note that sometimes it makes sense to rebuild all packages, including > noarch ones, e.g. when there are significant rpm-build, redhat-rpm-config > etc. changes that affect all packages. -- 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 17 12:10:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 17 Apr 2007 14:10:50 +0200 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <4624B025.10205@leemhuis.info> References: <20070417054814.GA11690@redhat.com> <462467B4.8000608@leemhuis.info> <20070417074204.GF5695@neu.nirvana> <462481D7.5050802@leemhuis.info> <20070417083515.GH5695@neu.nirvana> <46248EFA.40304@leemhuis.info> <20070417093215.GM5695@neu.nirvana> <46249F29.9090003@leemhuis.info> <20070417110548.GN5695@neu.nirvana> <4624B025.10205@leemhuis.info> Message-ID: <20070417121050.GP5695@neu.nirvana> On Tue, Apr 17, 2007 at 01:31:49PM +0200, Thorsten Leemhuis wrote: > > > On 17.04.2007 13:05, Axel Thimm wrote: > >On Tue, Apr 17, 2007 at 12:19:21PM +0200, Thorsten Leemhuis wrote: > >>>And it comes as no suprise since as we all should know FE was always > >>>doing mass rebuilds until including FC6. I wonder how the 0.6% and 1% > >>>were forgotten in the process. Perhaps someone did a rebuild with the > >>>same EVR - we didn't catch these in the old days. > >>We never did full rebuilds. Data-packages never had to be rebuild. > >OK, that accounts for the 0.6-1% then. [...] > > Well, you carefully didn't reply to the part where I explained that you > can't get to a proper number "how many packages weren't rebuild in the > devel cycle FE5 -> FE6" by looking at todays repos. So the 0.6-1% are > FUD in my eyes. Please be careful with using the word FUD. Not everything that doesn't suit your needs is FUD. > I don't have hard numbers either -- but from memory I'd say we didn't > rebuild round about 1/3 of the packages in the FE mass rebuild for FC6. Your memory doesn't serve you well. You even asked for two mass rebuilds for FC6, one for new rpm signing/sped up dynamic linking/new minimal buildroots and another "semi-mass rebuild" for fixing the gdb-backtrace bug for packages build in September. In fact all (but 1%) packages in FE6 got rebuilt at least once. On Sun, Jan 15, 2006 at 07:59:20PM +0100, Thorsten Leemhuis wrote: > We probably will have to do a rebuild of all (most?) packages in > Fedora Extras before FC5 is released. Why? Some reasons: On Sat, Jul 01, 2006 at 12:25:54PM +0200, Thorsten Leemhuis wrote: > Now it makes four good reasons to build all Extras packages in devel > before FC6. On Sat, Dec 09, 2006 at 07:13:16PM +0100, Thorsten Leemhuis wrote: > Yes, we did a lot of mass-rebuilds in for the last releases, -- 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 jakub at redhat.com Tue Apr 17 12:34:21 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 17 Apr 2007 08:34:21 -0400 Subject: Release Engineering Meeting Recap from Monday 16-APR-07 In-Reply-To: <20070417115651.GO5695@neu.nirvana> References: <46244EE2.5060002@redhat.com> <4624540C.7010109@leemhuis.info> <20070417081311.GG5695@neu.nirvana> <20070417110039.GK355@devserv.devel.redhat.com> <20070417115651.GO5695@neu.nirvana> Message-ID: <20070417123421.GL355@devserv.devel.redhat.com> On Tue, Apr 17, 2007 at 01:56:51PM +0200, Axel Thimm wrote: > > Even the glibc changes in F7 are mostly glibc internal changes, bugfixes > > and addition of a few new symbols (epoll_wait, sync_file_range, > > strerror_l, __sched_cpucount) and only on PPC a new version for existing > > symbols (pthread_attr_setstack{,size}). So neither gcc nor glibc > > changes necessitate a mass rebuild (and I'm not aware of any huge changes > > in redhat-rpm-config either) at this time and that's why F7 rebuild status > > is so low. GCC 4.2 has been stagnating for 6 months now and we have > > several important things backported anyway in GCC 4.1.x-RH (OpenMP, > > visibility stuff, Java stack, numerous Fortran improvements, many bugfixes, > > ...). > > When did these backports happen between 4.1.1-30 and 4.1.2-8 or earlier? Java stack rebase is in F7+ only, OpenMP/visibility stuff/most of Fortran improvements were already in FC6. Bug fixes are obviously continuously coming, be it from upstream gcc-4_1-branch or backports of fixes from GCC trunk or gcc-4_2-branch. > > If gcc, binutils or glibc changes substantially in say F8, we'll > > of course need to do a mass rebuild. > > gcc should finally have made it to 4.2 by then. Except it is unclear whether 4.2 is a win, while it has some advantages, it has also pretty significant drop in performance of compiled code (due to quick aliasing fixes), which is really fixed without performance degradation only in 4.3+. While this is not so severe for upstream 4.2 which compares to vanilla 4.1, as redhat/gcc-4_1-branch contains e.g. the i?86/x86_64 CPU tuning improvements (-mtune=generic, -m{arch,tune}={core2,amdfam10,geode}), when comparing redhat/gcc-4_1-branch to gcc-4_2-branch this is more visible. 4.3 has a lot of other goodies we are looking for, but we can't predict ATM how long will it take till 4.3 release, if it will stagnate the same way as 4.2 is or not. 4.2 actual development stages weren't terribly long, but after branching it has been 6 months with little activity, bugfixing where significant portion of the bugfixes went also to gcc-4_1-branch. Jakub From caillon at redhat.com Tue Apr 17 18:20:05 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 17 Apr 2007 14:20:05 -0400 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <4623D4F4.4050305@fedoraproject.org> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <4623D4F4.4050305@fedoraproject.org> Message-ID: <46250FD5.5000206@redhat.com> Rahul Sundaram wrote: > Jeff Spaleta wrote: >> Do additional exceptions tacked on to the GPL require a legal review >> or is this a best judgement situation? > > The rule of thumb when dealing with GPL exceptions is [...] If you are not a lawyer avoid assuming what can be done. [1] [1] https://www.redhat.com/archives/fedora-desktop-list/2007-April/msg00020.html From ssorce at redhat.com Tue Apr 17 18:34:22 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 17 Apr 2007 14:34:22 -0400 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> Message-ID: <1176834862.11319.73.camel@willson> On Mon, 2007-04-16 at 16:41 -0800, Jeff Spaleta wrote: > On 4/16/07, Tom spot Callaway wrote: > > Probably the former. Please post the license text, or throw the bugzilla > > number at me. > > pigment ticket: 233597 > elisa ticket: 233598 > > both have the same additional clause. The text of the additional clause is: > > Fluendo hereby grants permission for anyone under a valid license distributing > Fluendo's non-GPL compatible GStreamer plugins to distribute and use them > together with GStreamer and Elisa. This permission is above and beyond the > permissions granted by the GPL license by which Elisa is covered. If you > modify this code, you may extend this permission to your version of the code, > but you are not obligated to do so. If you do not wish to do so, delete this > exception statement from your version. > > > Like I said this looks fine to me, but I hadn't run across an > exceptions situation yet in a review. So pigment and elisa don't use _any_ other GPLed code that is not owned by themselves (libraries?) ? Simo. From sundaram at fedoraproject.org Tue Apr 17 18:35:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Apr 2007 00:05:41 +0530 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <46250FD5.5000206@redhat.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <4623D4F4.4050305@fedoraproject.org> <46250FD5.5000206@redhat.com> Message-ID: <4625137D.40906@fedoraproject.org> Christopher Aillon wrote: > Rahul Sundaram wrote: >> Jeff Spaleta wrote: >>> Do additional exceptions tacked on to the GPL require a legal review >>> or is this a best judgement situation? >> >> The rule of thumb when dealing with GPL exceptions is > [...] > > If you are not a lawyer avoid assuming what can be done. [1] > > > [1] > https://www.redhat.com/archives/fedora-desktop-list/2007-April/msg00020.html Fortunately here I don't assume. I asked. Besides I did add sufficient disclaimers. So what's your point? Rahul From caillon at redhat.com Tue Apr 17 18:46:49 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 17 Apr 2007 14:46:49 -0400 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <4625137D.40906@fedoraproject.org> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <4623D4F4.4050305@fedoraproject.org> <46250FD5.5000206@redhat.com> <4625137D.40906@fedoraproject.org> Message-ID: <46251619.3000101@redhat.com> Rahul Sundaram wrote: > Christopher Aillon wrote: >> Rahul Sundaram wrote: >>> Jeff Spaleta wrote: >>>> Do additional exceptions tacked on to the GPL require a legal review >>>> or is this a best judgement situation? >>> >>> The rule of thumb when dealing with GPL exceptions is >> [...] >> >> If you are not a lawyer avoid assuming what can be done. [1] >> >> >> [1] >> https://www.redhat.com/archives/fedora-desktop-list/2007-April/msg00020.html > > > Fortunately here I don't assume. I asked. Besides I did add sufficient > disclaimers. So what's your point? In the post I replied to, I saw no disclaimers nor mention of who, if anybody, in legal you asked. On top of that, you ended with a note that it "seems ok" to you, which can be construed as legal advice. My point is that without knowing where your information is coming from, it appears that you're making assumptions which could be wrong. It's one thing when you do that about various code-level or distribution-level items, but a whole different ballgame with legal affairs. Please avoid doing that. From sundaram at fedoraproject.org Tue Apr 17 19:19:10 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Apr 2007 00:49:10 +0530 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <46251619.3000101@redhat.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <4623D4F4.4050305@fedoraproject.org> <46250FD5.5000206@redhat.com> <4625137D.40906@fedoraproject.org> <46251619.3000101@redhat.com> Message-ID: <46251DAE.6010607@fedoraproject.org> Christopher Aillon wrote: > In the post I replied to, I saw no disclaimers nor mention of who, if > anybody, in legal you asked. When I wrote some licensing related articles for Red Hat I have been involved with Red Hat legal. I have also talked with FSF extensively on GPL related issues on various occasions including Eben Moglen in this specific topic in person. On top of that, you ended with a note that > it "seems ok" to you, which can be construed as legal advice. "Seems ok to me" is specifically meant to clarify that this is a personal judgmental call rather than as a clear cut legal statement. When we deal with legal issues we either work by consensus which is way faster or go to the legal team for additional clarifications on instances which is way slower. We do work as a community and judge the licenses ourselves in every single package review. Are you suggesting that we consult Red Hat legal on every single license? Rahul From tibbs at math.uh.edu Tue Apr 17 23:33:08 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 17 Apr 2007 18:33:08 -0500 Subject: Summary of the 2007-04-17 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging meeting which occurred on 2007.04.17 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070417 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * A statement of the responsibilities of reviewers and packagers during the package review process http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals * Guidelines for conflicting packages and the use of Conflicts: http://fedoraproject.org/wiki/PackagingDrafts/Conflicts These should be written into the guidelines soon if this hasn't already been done by the time you read this. Issues pending FESCO ratification: * Minor clarifications to the filename encoding guidelines: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00156.html * The guidelines contained a few references to fedora-extras-list; these have been altered to point to fedora-devel-list instead. We went ahead and made the change because extras-list is gone, but FESCO should ack these changes. Misc business: * The Committee waded with much trepidation into the issue of guidelines for the creation of users and groups. This is a complex issue which I won't attempt to summarize, but it will require significantly more discussion. * Meeting time: We'll have to block out time in a wiki table and try to narrow something down. At the moment it looks like 1600UTC satisfies the most people, except for cutting into f13's lunchtime. - J< From jspaleta at gmail.com Wed Apr 18 00:27:26 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 17 Apr 2007 16:27:26 -0800 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <1176834862.11319.73.camel@willson> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> <1176834862.11319.73.camel@willson> Message-ID: <604aa7910704171727s6ee9d878i9f828461036fa938@mail.gmail.com> On 4/17/07, Simo Sorce wrote: > So pigment and elisa don't use _any_ other GPLed code that is not owned > by themselves (libraries?) ? For the purposes of the review process... i don't think this question matters because gstreamer is itself licensed under LGPL so using closed libraries inside gstreamer plugins as fluendo does is an acceptable practice allowed by the LGPL. I think this exceptional clause is aimed primarily at people who would like to distribute elisa with additional binary only gstreamer plugins... which Fedora isn't going to be doing in the official tree. I also think the fact that the additional exceptional clause is revocable by any downstream entity makes its okay to allow for the purposes of the review process. If the exception is found to be invalid legally then such a ruling only hinders the distributors of the non-GPL'd fluendo plugins who were relying on that particular exception clause. Since fedora does not distribute the code which must rely on the rights of the exceptional clause, the exceptional clause does not come into play with regard to how elisa and pigment are to be built, packaged or distributed inside the Fedora repository. But here again, I'm not a laywer, and while the consensus opinion of the developers who've had experience with exceptional GPL clause appear to think this is not a particularly exotic version, I'm still interested in a competent legal ruling. -jef From sundaram at fedoraproject.org Wed Apr 18 00:35:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Apr 2007 06:05:34 +0530 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: References: Message-ID: <462567D6.4020406@fedoraproject.org> Jason L Tibbitts III wrote: > Meeting minutes and full logs of the packaging meeting which occurred > on 2007.04.17 are online: > > http://fedoraproject.org/wiki/Packaging/Minutes > http://fedoraproject.org/wiki/Packaging/Minutes20070417 > > Executive summary: > > The following drafts are now official guidelines, having been accepted > by FESCO last week: > * A statement of the responsibilities of reviewers and packagers during > the package review process > http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals > > * Guidelines for conflicting packages and the use of Conflicts: > http://fedoraproject.org/wiki/PackagingDrafts/Conflicts > > These should be written into the guidelines soon if this hasn't > already been done by the time you read this. > > Issues pending FESCO ratification: > * Minor clarifications to the filename encoding guidelines: > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00156.html > > * The guidelines contained a few references to fedora-extras-list; > these have been altered to point to fedora-devel-list instead. > We went ahead and made the change because extras-list is gone, but > FESCO should ack these changes. Can you remove all references to core and extras from the guidelines? FESCo is Fedora Engineering Steering Committee now. Rahul From tcallawa at redhat.com Wed Apr 18 00:36:22 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 17 Apr 2007 19:36:22 -0500 Subject: Question on how to handled "GPL with exceptions" in a package review. In-Reply-To: <604aa7910704171727s6ee9d878i9f828461036fa938@mail.gmail.com> References: <604aa7910704161244x2c78e7b6jd5e2dea42d709952@mail.gmail.com> <1176752790.3970.360.camel@localhost.localdomain> <604aa7910704161741k13bcd806q4e403e7717d5d6f4@mail.gmail.com> <1176834862.11319.73.camel@willson> <604aa7910704171727s6ee9d878i9f828461036fa938@mail.gmail.com> Message-ID: <1176856582.4182.30.camel@localhost.localdomain> On Tue, 2007-04-17 at 16:27 -0800, Jeff Spaleta wrote: > But here again, I'm not a laywer, and while the consensus opinion of > the developers who've had experience with exceptional GPL clause > appear to think this is not a particularly exotic version, I'm still > interested in a competent legal ruling. IANAL, and my competence is questionable, but the license is OK for Fedora. ~spot From jkeating at redhat.com Wed Apr 18 01:11:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Apr 2007 21:11:26 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <200704131534.15954.jkeating@redhat.com> References: <200704131534.15954.jkeating@redhat.com> Message-ID: <200704172111.26773.jkeating@redhat.com> On Friday 13 April 2007 15:34:15 Jesse Keating wrote: > This will also mark the point in which I'd like to enter a continual slushy > state. ?Only bugfixes going in, with low risk to breaking other things. > > See http://fedoraproject.org/wiki/Releases/DevelFreezePolicy for policy on > getting things tagged for the freeze tag for now until the end of the F7 > cycle. Test 4 is frozen. Brr... -- 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 Wed Apr 18 05:20:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Apr 2007 07:20:34 +0200 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: References: Message-ID: <4625AAA2.8070808@leemhuis.info> Hi! On 18.04.2007 01:33, Jason L Tibbitts III wrote: > > * The guidelines contained a few references to fedora-extras-list; > these have been altered to point to fedora-devel-list instead. > We went ahead and made the change because extras-list is gone, but > FESCO should ack these changes. Well, some people accuse me of formalizing everything to much and putting to much government structures into Fedora (they might have a point, but that's another discussion). But reading the above I'm starting myself to wonder: does FESCo really want and have to look at such issue like adjusting references to fedora-extras-list? Sending the adjustments that are going to be made to the list (where FESCo members as well as ordinary packagers can jump in if they don't like something) and discussing them in FPC IMHO should be more than enough I'd say. > * Meeting time: We'll have to block out time in a wiki table and try > to narrow something down. At the moment it looks like 1600UTC > satisfies the most people, except for cutting into f13's lunchtime. BTW, it's not my business as I'm not in the FPC, but I thought I mention it here as I'm writing this mail anyway already: most meetings times seems to take the DST switch into account and adjust the UTC meeting time by an hour so the effective time always stays round about (?) the same for US and Europe. Wouldn't that be a solution for the FPC, too? Just my 2 cent. CU thl (?) -- the switches are on different dates these days, so there are two or three weeks where it's getting a bit mor complicated :-/ From buildsys at fedoraproject.org Wed Apr 18 07:48:12 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 18 Apr 2007 03:48:12 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-18 Message-ID: <20070418074812.816B6152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) ---------------------------------------------------------------------- gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) From a.badger at gmail.com Wed Apr 18 09:19:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 18 Apr 2007 02:19:34 -0700 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: <4625AAA2.8070808@leemhuis.info> References: <4625AAA2.8070808@leemhuis.info> Message-ID: <1176887974.25462.23.camel@localhost.localdomain> On Wed, 2007-04-18 at 07:20 +0200, Thorsten Leemhuis wrote: > Hi! > > On 18.04.2007 01:33, Jason L Tibbitts III wrote: > > * Meeting time: We'll have to block out time in a wiki table and try > > to narrow something down. At the moment it looks like 1600UTC > > satisfies the most people, except for cutting into f13's lunchtime. > > BTW, it's not my business as I'm not in the FPC, but I thought I mention > it here as I'm writing this mail anyway already: most meetings times > seems to take the DST switch into account and adjust the UTC meeting > time by an hour so the effective time always stays round about (?) the > same for US and Europe. Wouldn't that be a solution for the FPC, too? > > Just my 2 cent. > > CU > thl > > (?) -- the switches are on different dates these days, so there are two > or three weeks where it's getting a bit mor complicated :-/ > The meeting time was supposed to adjust with DST. But with the time shift happening at two different times, we decided to hold off on changing the time until Europe had also gone to DST. And then someone mentioned that the time in the interim week suited them better. And then.... -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 jonathan.underwood at gmail.com Wed Apr 18 10:37:32 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 18 Apr 2007 11:37:32 +0100 Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <20070416163616.GM19042@neu.nirvana> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> <20070416154615.GI19042@neu.nirvana> <28703.65.192.24.190.1176738699.squirrel@mail.jcomserv.net> <20070416160508.GJ19042@neu.nirvana> <30149.65.192.24.190.1176739742.squirrel@mail.jcomserv.net> <20070416163616.GM19042@neu.nirvana> Message-ID: <645d17210704180337g328d1219qdee61c53504d36dd@mail.gmail.com> On 16/04/07, Axel Thimm wrote: > I just did. Some parts like x86_64 support are already in, also some > mismatching lib issues, the update requests and some crashes. > > What I know still exists as an issue is printing support, as this > doesn't really exists in upstream either. One thing I did notice about the nx packaging is that it breaks the one tarball to one package paradigm, having something like 9 tarballs rolled into it. Do the sources really all need to be in the build tree at the same time, or could the packaging be cleaned up? From Axel.Thimm at ATrpms.net Wed Apr 18 10:49:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 18 Apr 2007 12:49:39 +0200 Subject: NX/FreeNX maintainer: AWOL? In-Reply-To: <645d17210704180337g328d1219qdee61c53504d36dd@mail.gmail.com> References: <11391.65.192.24.190.1176474266.squirrel@mail.jcomserv.net> <20070413165759.GD32753@neu.nirvana> <22238.65.192.24.190.1176734001.squirrel@mail.jcomserv.net> <20070416154615.GI19042@neu.nirvana> <28703.65.192.24.190.1176738699.squirrel@mail.jcomserv.net> <20070416160508.GJ19042@neu.nirvana> <30149.65.192.24.190.1176739742.squirrel@mail.jcomserv.net> <20070416163616.GM19042@neu.nirvana> <645d17210704180337g328d1219qdee61c53504d36dd@mail.gmail.com> Message-ID: <20070418104939.GA31243@neu.nirvana> On Wed, Apr 18, 2007 at 11:37:32AM +0100, Jonathan Underwood wrote: > On 16/04/07, Axel Thimm wrote: > >I just did. Some parts like x86_64 support are already in, also some > >mismatching lib issues, the update requests and some crashes. > > > >What I know still exists as an issue is printing support, as this > >doesn't really exists in upstream either. > > One thing I did notice about the nx packaging is that it breaks the > one tarball to one package paradigm, having something like 9 tarballs > rolled into it. Do the sources really all need to be in the build tree > at the same time, or could the packaging be cleaned up? I'd also like to see the package split up, and was discussing this with Rick some ages ago, even before the packages made it into extras. Other distros also split the megapackage up into conventional packages. But I would not do too many things at one time. Let's address this after the AWOL procedure, OK? -- 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 j.w.r.degoede at hhs.nl Wed Apr 18 13:22:18 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 18 Apr 2007 15:22:18 +0200 Subject: Father Message-ID: <46261B8A.9090409@hhs.nl> Hi all, This morning, 10.35 CET, I've become the father of a daughter for the second time. Her names is Eowyn and she ways 3.5 Kg. Both mother and daughter are well. Regards, Hans p.s. I'm sure you'll all understand that this means that the coming time I might be a little less responsive to bugreports / reviews / mails then I normally am. From limb at jcomserv.net Wed Apr 18 13:03:46 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 18 Apr 2007 08:03:46 -0500 (CDT) Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: <63337.65.192.24.190.1176901426.squirrel@mail.jcomserv.net> Congratulations! Don't forget to sleep. . .:) > Hi all, > > This morning, 10.35 CET, I've become the father of a daughter for the > second > time. Her names is Eowyn and she ways 3.5 Kg. > > Both mother and daughter are well. > > Regards, > > Hans > > > p.s. > > I'm sure you'll all understand that this means that the coming time I > might be > a little less responsive to bugreports / reviews / mails then I normally > am. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From j.w.r.degoede at hhs.nl Wed Apr 18 13:26:19 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 18 Apr 2007 15:26:19 +0200 Subject: broken deps outside of packagers control Message-ID: <46261C7B.4020404@hhs.nl> Hi all, I just got this mail from the broken deps check script: --- This is an automated mail created by an experimental script. Your following packages in the repository contain broken dependencies: ====================================================================== The results in this report consider unreleased updates in the build-system's needsign-queue! ====================================================================== package: gnumeric - 1:1.6.3-6.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libperl.so --- This raises 2 issues: 1 Notice how the deps are only broken for the i386 version in the x86_64 tree, this is something outside my control. If script XXX decides to put a i386 gnumeric in the x86_64 tree, then the script should also make sure it puts in all need deps from the i386 tree 2 Why does the script put the i386 version of gnumeric (an application) in the x86_64 tree at all? That just doesn't make sense. Regards, Hans From lemenkov at gmail.com Wed Apr 18 13:26:22 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 18 Apr 2007 17:26:22 +0400 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: 2007/4/18, Hans de Goede : > Hi all, > > This morning, 10.35 CET, I've become the father of a daughter for the second > time. Her names is Eowyn and she ways 3.5 Kg. > > Both mother and daughter are well. Congrats! I'll whip one or two drinks ) -- With best regards! From fedora at leemhuis.info Wed Apr 18 13:32:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Apr 2007 15:32:53 +0200 Subject: broken deps outside of packagers control In-Reply-To: <46261C7B.4020404@hhs.nl> References: <46261C7B.4020404@hhs.nl> Message-ID: <46261E05.1090708@leemhuis.info> On 18.04.2007 15:26, Hans de Goede wrote: > [...] > This raises 2 issues: > 1 Notice how the deps are only broken for the i386 version in the x86_64 tree, > this is something outside my control. If script XXX decides to put a i386 > gnumeric in the x86_64 tree, then the script should also make sure it puts in > all need deps from the i386 tree perl.i386 was in the Core tree but got removed without proper announcement/discussion beforehand (and even worse: that happened on the day of the feature freeze). See https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01004.html > 2 Why does the script put the i386 version of gnumeric (an application) in > the x86_64 tree at all? That just doesn't make sense. I assume because there is a gnumeric-devel (the multilib-magic scripts afaik try to track in most of the devel packages, which thus tracks in the main package normally, too). CU thl From oliver at linux-kernel.at Wed Apr 18 13:33:36 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 18 Apr 2007 15:33:36 +0200 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: <46261E30.5000905@linux-kernel.at> On 04/18/2007 03:22 PM, Hans de Goede wrote: > This morning, 10.35 CET, I've become the father of a daughter for the > second time. Her names is Eowyn and she ways 3.5 Kg. > > Both mother and daughter are well. > > Regards, > > Hans > > > p.s. > > I'm sure you'll all understand that this means that the coming time I > might be a little less responsive to bugreports / reviews / mails then I > normally am. Congrats, Hans! My twins are almost 1 year old (2006-04-24). Get some sleep as long as you are able to sleep! Best, Oliver From jima at beer.tclug.org Wed Apr 18 13:35:08 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 18 Apr 2007 08:35:08 -0500 (CDT) Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: On Wed, 18 Apr 2007, Hans de Goede wrote: > This morning, 10.35 CET, I've become the father of a daughter for the second > time. Her names is Eowyn and she ways 3.5 Kg. > > Both mother and daughter are well. Congratulations! :-) Even more startling is that you replied to an email of mine 3.5 hours prior...and you're still alive? Sheerly remarkable. *ducks and covers* Jima From j.w.r.degoede at hhs.nl Wed Apr 18 13:58:08 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 18 Apr 2007 15:58:08 +0200 Subject: Father In-Reply-To: References: <46261B8A.9090409@hhs.nl> Message-ID: <462623F0.6020304@hhs.nl> Jima wrote: > On Wed, 18 Apr 2007, Hans de Goede wrote: >> This morning, 10.35 CET, I've become the father of a daughter for the >> second time. Her names is Eowyn and she ways 3.5 Kg. >> >> Both mother and daughter are well. > > Congratulations! :-) > Even more startling is that you replied to an email of mine 3.5 hours > prior...and you're still alive? Sheerly remarkable. > *ducks and covers* > Well what can I say? It was a remarkable quick delivery. Regards, Hans From tcallawa at redhat.com Wed Apr 18 13:54:04 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 18 Apr 2007 08:54:04 -0500 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: <1176904444.5413.3.camel@localhost.localdomain> On Wed, 2007-04-18 at 15:22 +0200, Hans de Goede wrote: > Hi all, > > This morning, 10.35 CET, I've become the father of a daughter for the second > time. Her names is Eowyn and she ways 3.5 Kg. Congratulations! Let us know when we should setup CVS access for her. :) ~spot From limb at jcomserv.net Wed Apr 18 13:52:33 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 18 Apr 2007 08:52:33 -0500 (CDT) Subject: Father In-Reply-To: <1176904444.5413.3.camel@localhost.localdomain> References: <46261B8A.9090409@hhs.nl> <1176904444.5413.3.camel@localhost.localdomain> Message-ID: <3034.65.192.24.190.1176904353.squirrel@mail.jcomserv.net> Doesn't she have to be sponsored first? If not, I have a very bright 2-year old, she'd love to contribute! ;) > On Wed, 2007-04-18 at 15:22 +0200, Hans de Goede wrote: >> Hi all, >> >> This morning, 10.35 CET, I've become the father of a daughter for the >> second >> time. Her names is Eowyn and she ways 3.5 Kg. > > Congratulations! Let us know when we should setup CVS access for her. :) > > ~spot > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From oliver at linux-kernel.at Wed Apr 18 13:56:51 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 18 Apr 2007 15:56:51 +0200 Subject: Father In-Reply-To: <1176904444.5413.3.camel@localhost.localdomain> References: <46261B8A.9090409@hhs.nl> <1176904444.5413.3.camel@localhost.localdomain> Message-ID: <462623A3.9000707@linux-kernel.at> On 04/18/2007 03:54 PM, Tom "spot" Callaway wrote: > On Wed, 2007-04-18 at 15:22 +0200, Hans de Goede wrote: >> Hi all, >> >> This morning, 10.35 CET, I've become the father of a daughter for the second >> time. Her names is Eowyn and she ways 3.5 Kg. > > Congratulations! Let us know when we should setup CVS access for her. :) Wouldn't this be child labor? :-) -of From tjanouse at redhat.com Wed Apr 18 13:59:38 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Wed, 18 Apr 2007 15:59:38 +0200 Subject: broken deps outside of packagers control In-Reply-To: <46261E05.1090708@leemhuis.info> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> Message-ID: <20070418135938.GA18203@redhat.com> Hi, On Wed, Apr 18, 2007 at 03:32:53PM +0200, Thorsten Leemhuis wrote: > I assume because there is a gnumeric-devel (the multilib-magic scripts > afaik try to track in most of the devel packages, which thus tracks in > the main package normally, too). Is there any way to look at those? Or some documentation that clearly says what packages are marked multilib. I googled as hell and didn't find anything. -- TJ. (Brno, CZ), BaseOS, Red Hat From tcallawa at redhat.com Wed Apr 18 14:04:54 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 18 Apr 2007 09:04:54 -0500 Subject: Father In-Reply-To: <462623A3.9000707@linux-kernel.at> References: <46261B8A.9090409@hhs.nl> <1176904444.5413.3.camel@localhost.localdomain> <462623A3.9000707@linux-kernel.at> Message-ID: <1176905094.5413.4.camel@localhost.localdomain> On Wed, 2007-04-18 at 15:56 +0200, Oliver Falk wrote: > On 04/18/2007 03:54 PM, Tom "spot" Callaway wrote: > > On Wed, 2007-04-18 at 15:22 +0200, Hans de Goede wrote: > >> Hi all, > >> > >> This morning, 10.35 CET, I've become the father of a daughter for the second > >> time. Her names is Eowyn and she ways 3.5 Kg. > > > > Congratulations! Let us know when we should setup CVS access for her. :) > > Wouldn't this be child labor? :-) Sure! Those kids don't work hard enough these days. ;) ~spot From peter at thecodergeek.com Wed Apr 18 14:05:37 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 18 Apr 2007 07:05:37 -0700 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: <1176905137.3360.2.camel@tuxhugs> On Wed, 2007-04-18 at 15:22 +0200, Hans de Goede wrote: > This morning, 10.35 CET, I've become the father of a daughter for the second > time. Her names is Eowyn and she ways 3.5 Kg. Congrats, Hans! My best wishes to your family and its new member. :) (Though if you don't mind my asking, is her name Tolkien-inspired?) -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 jima at beer.tclug.org Wed Apr 18 14:07:44 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 18 Apr 2007 09:07:44 -0500 (CDT) Subject: Father In-Reply-To: <3034.65.192.24.190.1176904353.squirrel@mail.jcomserv.net> References: <46261B8A.9090409@hhs.nl> <1176904444.5413.3.camel@localhost.localdomain> <3034.65.192.24.190.1176904353.squirrel@mail.jcomserv.net> Message-ID: On Wed, 18 Apr 2007, Jon Ciesla wrote: > Doesn't she have to be sponsored first? If not, I have a very bright > 2-year old, she'd love to contribute! ;) Hans is a sponsor. I think he can handle the mentoring and guidance for his little packager (although I'm not sure we want to distribute what she'll be packaging anytime soon...). Jima From bnocera at redhat.com Wed Apr 18 14:10:33 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Wed, 18 Apr 2007 15:10:33 +0100 Subject: Oprhaning driftnet Message-ID: <1176905433.32379.27.camel@cookie.hadess.net> Heya, I'm not using driftnet at all, and wanted to orphan it. The only opened bug is at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201412 And can be fixed by using the gtk2 port used in the debian package, instead of mine. Cheers From bugs.michael at gmx.net Wed Apr 18 14:14:08 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 18 Apr 2007 16:14:08 +0200 Subject: broken deps outside of packagers control In-Reply-To: <46261E05.1090708@leemhuis.info> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> Message-ID: <20070418161408.771af0fe.bugs.michael@gmx.net> On Wed, 18 Apr 2007 15:32:53 +0200, Thorsten Leemhuis wrote: > On 18.04.2007 15:26, Hans de Goede wrote: > > [...] > > This raises 2 issues: ... which could have been posted in a less reproachful way. > > 1 Notice how the deps are only broken for the i386 version in the x86_64 tree, > > this is something outside my control. If script XXX decides to put a i386 > > gnumeric in the x86_64 tree, then the script should also make sure it puts in > > all need deps from the i386 tree It does. But Core and Extras are not merged yet, so it cannot do anything inside the Core repo. > perl.i386 was in the Core tree but got removed without proper > announcement/discussion beforehand (and even worse: that happened on the > day of the feature freeze). See > https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01004.html Also note that if gaim had stayed in Core, it would now be broken in Core x86_64 due to this removal of perl.i386. [FC6 ships gaim.i386 and perl.i386 for x86_64] > > 2 Why does the script put the i386 version of gnumeric (an application) in > > the x86_64 tree at all? That just doesn't make sense. > > I assume because there is a gnumeric-devel (the multilib-magic scripts > afaik try to track in most of the devel packages, which thus tracks in > the main package normally, too). Yes. And that means, this issue is _not_ "outside packager's control", because in most of the cases the packager *could* split off a sub-package and adjust the -devel pkg requirements accordingly. However, (!) whether this is the way to go with these broken deps this time, too, or whether to exclude them from the multi-lib pushscript, needs further investigation. From bpepple at fedoraproject.org Wed Apr 18 14:16:43 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Apr 2007 10:16:43 -0400 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: <4625AAA2.8070808@leemhuis.info> References: <4625AAA2.8070808@leemhuis.info> Message-ID: <1176905803.6145.3.camel@lincoln> On Wed, 2007-04-18 at 07:20 +0200, Thorsten Leemhuis wrote: > On 18.04.2007 01:33, Jason L Tibbitts III wrote: > > > > * The guidelines contained a few references to fedora-extras-list; > > these have been altered to point to fedora-devel-list instead. > > We went ahead and made the change because extras-list is gone, but > > FESCO should ack these changes. > > Well, some people accuse me of formalizing everything to much and > putting to much government structures into Fedora (they might have a > point, but that's another discussion). But reading the above I'm > starting myself to wonder: does FESCo really want and have to look at > such issue like adjusting references to fedora-extras-list? Sending the > adjustments that are going to be made to the list (where FESCo members > as well as ordinary packagers can jump in if they don't like something) > and discussing them in FPC IMHO should be more than enough I'd say. I'm in agreement with Thorsten on this. I think issues like this don't need FESCo's ack. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 oliver at linux-kernel.at Wed Apr 18 14:27:21 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 18 Apr 2007 16:27:21 +0200 Subject: Father In-Reply-To: References: <46261B8A.9090409@hhs.nl> <1176904444.5413.3.camel@localhost.localdomain> <3034.65.192.24.190.1176904353.squirrel@mail.jcomserv.net> Message-ID: <46262AC9.5000600@linux-kernel.at> On 04/18/2007 04:07 PM, Jima wrote: > On Wed, 18 Apr 2007, Jon Ciesla wrote: >> Doesn't she have to be sponsored first? If not, I have a very bright >> 2-year old, she'd love to contribute! ;) > > Hans is a sponsor. I think he can handle the mentoring and guidance > for his little packager (although I'm not sure we want to distribute > what she'll be packaging anytime soon...). Right. Else, I would also send you a whole bunch of Marlene's and Paul's 'packages' :-) -of From bugs.michael at gmx.net Wed Apr 18 14:34:31 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 18 Apr 2007 16:34:31 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070418135938.GA18203@redhat.com> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> Message-ID: <20070418163431.5a502c29.bugs.michael@gmx.net> On Wed, 18 Apr 2007 15:59:38 +0200, Tomas Janousek wrote: > Hi, > > On Wed, Apr 18, 2007 at 03:32:53PM +0200, Thorsten Leemhuis wrote: > > I assume because there is a gnumeric-devel (the multilib-magic scripts > > afaik try to track in most of the devel packages, which thus tracks in > > the main package normally, too). > > Is there any way to look at those? Or some documentation that clearly says > what packages are marked multilib. I googled as hell and didn't find anything. > For Extras: -devel packages (including virtual ones) plus their dependency chains plus any packages we put on the whitelist and minus any packages we put on the blacklist. Currently, only "gnustep-make" is blacklisted, and the "wine" package set is whitelisted. The two lists are in fedora cvs: extras-buildsys/utils/pushscript/Config_Extras.py From bpepple at fedoraproject.org Wed Apr 18 14:31:14 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Apr 2007 10:31:14 -0400 Subject: FESCo Meeting Summary for 2007-04-12 Message-ID: <1176906674.6145.8.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (c4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) * Jeremy Katz (jeremy) * Jesse Keating (f13) * Bill Nottingham (notting) === Absent === * Tom Callaway (spot) * Warren Togami (warren) == Summary == === Packaging Committee Report === * FESCo approved the Packaging Committee's guidelines regarding: * http://fedoraproject.org/wiki/PackagingDrafts/OverallReviewGoals * http://fedoraproject.org/wiki/PackagingDrafts/Conflicts === Renaming cvsextras === * FESCo approved warren's proposal to rename the cvsextras group. === Koji === * f13 discussed the plans for the switch from plague to Koji in Extras. === EPEL === * FESCo voted against the plan to delete everything and then do a mass-rebuild for EPEL5, instead of bumping the spec and rebuilding. thl will inform the EPEL Steering Committe. === Package Conflicts === * bpepple received from Michael Schwendt the tool to identify packages with conflicts, but he hasn't had time to look at it. Also, still need someone to be lead on this. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070412 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Wed Apr 18 15:44:10 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 18 Apr 2007 10:44:10 -0500 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: <4625AAA2.8070808@leemhuis.info> References: <4625AAA2.8070808@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> But reading the above I'm starting myself to wonder: does FESCo TL> really want and have to look at such issue like adjusting TL> references to fedora-extras-list? Hey, whatever, I'm just following the rules. - J< From jwboyer at jdub.homelinux.org Wed Apr 18 16:09:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 18 Apr 2007 11:09:07 -0500 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: References: <4625AAA2.8070808@leemhuis.info> Message-ID: <1176912547.25513.33.camel@vader.jdub.homelinux.org> On Wed, 2007-04-18 at 10:44 -0500, Jason L Tibbitts III wrote: > >>>>> "TL" == Thorsten Leemhuis writes: > > TL> But reading the above I'm starting myself to wonder: does FESCo > TL> really want and have to look at such issue like adjusting > TL> references to fedora-extras-list? > > Hey, whatever, I'm just following the rules. Fortunately, our rules are more like guidelines. Garr! Thanks for pointing it out, but unless someone jumps up and down screaming, I think we're good with this change and it doesn't need an ACK. /me wonders how many people will get the movie reference. josh From Axel.Thimm at ATrpms.net Wed Apr 18 16:49:43 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 18 Apr 2007 18:49:43 +0200 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: References: <4625AAA2.8070808@leemhuis.info> Message-ID: <20070418164943.GC8167@neu.nirvana> On Wed, Apr 18, 2007 at 10:44:10AM -0500, Jason L Tibbitts III wrote: > > But reading the above I'm starting myself to wonder: does FESCo > > really want and have to look at such issue like adjusting > > references to fedora-extras-list? > > Hey, whatever, I'm just following the rules. And I think you're doing fine, because if we start to draw a line ourselves, the next issue we decide not to let fesco ack it will be one that fesco member will be upset we didn't pass it on. Since this looks like a noop, it will take less than 30 sec of fesco's time. If it takes more it looks like it was right to send along 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 fedora at leemhuis.info Wed Apr 18 16:54:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Apr 2007 18:54:00 +0200 Subject: Summary of the 2007-04-17 Packaging Committee meeting In-Reply-To: <1176912547.25513.33.camel@vader.jdub.homelinux.org> References: <4625AAA2.8070808@leemhuis.info> <1176912547.25513.33.camel@vader.jdub.homelinux.org> Message-ID: <46264D28.7000103@leemhuis.info> Josh Boyer schrieb: > On Wed, 2007-04-18 at 10:44 -0500, Jason L Tibbitts III wrote: >>>>>>> "TL" == Thorsten Leemhuis writes: >> TL> But reading the above I'm starting myself to wonder: does FESCo >> TL> really want and have to look at such issue like adjusting >> TL> references to fedora-extras-list? >> Hey, whatever, I'm just following the rules. Tibbs, I didn't mean to criticize your work. Your FPC reports are quite good and I really appreciate them a lot. Thanks for your work. > Fortunately, our rules are more like guidelines. Garr! Well, the only written rules/guidelines that I'm aware off are these: http://fedoraproject.org/wiki/Development/Schedule "A representative from the packaging committee will send a report after each committee meeting to fedora-maintainers at redhat.com for public discussion. In order to give ample discussion time, this report should be sent no less than 24 hours before the next FESCo meeting; if the report is late, the veto period will be extended by one additional FESCo meeting. FESCo may also extend the veto period if there is still ongoing discussion." There afaics isn't any mention of FESCo wanting to ACK each and everything. FESCo just wants to have a *chance* to veto stuff afaics -- and to be able to do that it of course needs to be aware of any major decisions the FPC did, thus there need to be public reports somewhere and some time for FESCo-members to yell. Same for EPEL btw (and EPEL is the reasons why I'm bringing this up in case anyone wonders). The veto period according to the above para can be quite long -- for EPEL (that meets 24 hours before FESCo) it's probably 8 days normally. Maybe that should be adjusted to make sure FPC, EPEL and other projects can move on in a timely manner without fearing that FESCo vetos stuff. So in other words to get the whole stuff sorted out we might want a guideline like this to make everyone happy: ---- Groups like EPEL or Fedora Packaging Committee have to send weekly reports of their important doings, meetings and the major decisions that were made to FESCo as well as a public mailing list for discussion. If two FESCo members don't like a particular decisions then they should say so on the list in less than three working days after the report got send and the decision is put on hold until the next FESCo meeting. The particular group at that point can decide to revisit the decision on it's own; if that doesn't happen FESCo will discuss the issue in its next meeting and can veto it for real if a majority of FESCo members agree to veto it in that meeting. A vetoed issue gets send back to the responsible committee with a suggestion from FESCo what should be done differently. ---- Does that direction sound sane? It should give groups like EPEL and FPC room to act on their own without having to get FESCo involved for each and every detail or without waiting for FESCo days before it ratifies a decision. On the other hand it gives FESCo members a chance to jump in if they don't like a particular decision. And yes, writing those reports and summaries is a lot of work and might feels like wasted overhead -- but groups like FPC or EPEL imho should invest that time anyway, to make everyone (FESCo, Fedora News, Board, general public, ...) a chance to know what's going on in their area, without forcing people to follow the details of each flamewar ^w discussion. > Thanks for pointing it out, but unless someone jumps up and down > screaming, I think we're good with this change and it doesn't need an > ACK. > > /me wonders how many people will get the movie reference. /me does not CU thl From j.w.r.degoede at hhs.nl Wed Apr 18 17:56:21 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 18 Apr 2007 19:56:21 +0200 Subject: Father In-Reply-To: <1176905137.3360.2.camel@tuxhugs> References: <46261B8A.9090409@hhs.nl> <1176905137.3360.2.camel@tuxhugs> Message-ID: <46265BC5.6000100@hhs.nl> Peter Gordon wrote: > On Wed, 2007-04-18 at 15:22 +0200, Hans de Goede wrote: >> This morning, 10.35 CET, I've become the father of a daughter for the second >> time. Her names is Eowyn and she ways 3.5 Kg. > > Congrats, Hans! My best wishes to your family and its new member. :) > > (Though if you don't mind my asking, is her name Tolkien-inspired?) > Yes and no, We were at the doctors for a regular checkup and there was a book with possible childrens names there, that is where the name Eowyn comes from, and according to that same book (and other sources) the name Eowyn indeed comes from Tolkien. Regards, Hans From j.w.r.degoede at hhs.nl Wed Apr 18 17:59:04 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 18 Apr 2007 19:59:04 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070418163431.5a502c29.bugs.michael@gmx.net> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> Message-ID: <46265C68.7050902@hhs.nl> Michael Schwendt wrote: > On Wed, 18 Apr 2007 15:59:38 +0200, Tomas Janousek wrote: > >> Hi, >> >> On Wed, Apr 18, 2007 at 03:32:53PM +0200, Thorsten Leemhuis wrote: >>> I assume because there is a gnumeric-devel (the multilib-magic scripts >>> afaik try to track in most of the devel packages, which thus tracks in >>> the main package normally, too). >> Is there any way to look at those? Or some documentation that clearly says >> what packages are marked multilib. I googled as hell and didn't find anything. >> > > For Extras: > > -devel packages (including virtual ones) plus their dependency chains plus > any packages we put on the whitelist and minus any packages we put on the > blacklist. > > Currently, only "gnustep-make" is blacklisted, and the "wine" package set > is whitelisted. The two lists are in fedora cvs: > extras-buildsys/utils/pushscript/Config_Extras.py > In that case can gnumeric please be blacklisted, and the i386 version removed from the x86_64 repo? Thanks & regards, Hans From orion at cora.nwra.com Wed Apr 18 18:10:28 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 18 Apr 2007 12:10:28 -0600 Subject: Father In-Reply-To: <46265BC5.6000100@hhs.nl> References: <46261B8A.9090409@hhs.nl> <1176905137.3360.2.camel@tuxhugs> <46265BC5.6000100@hhs.nl> Message-ID: <46265F14.10708@cora.nwra.com> Hans de Goede wrote: > Peter Gordon wrote: >> On Wed, 2007-04-18 at 15:22 +0200, Hans de Goede wrote: >>> This morning, 10.35 CET, I've become the father of a daughter for the >>> second time. Her names is Eowyn and she ways 3.5 Kg. >> >> Congrats, Hans! My best wishes to your family and its new member. :) >> >> (Though if you don't mind my asking, is her name Tolkien-inspired?) >> > > Yes and no, > > We were at the doctors for a regular checkup and there was a book with > possible childrens names there, that is where the name Eowyn comes from, > and according to that same book (and other sources) the name Eowyn > indeed comes from Tolkien. Congratulations Hans! (Our ?owyn arrived almost 3 years ago now. The Lord of the Rings trilogy is my wife's favorite books and gets re-read every year or two) -- 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 wtogami at redhat.com Wed Apr 18 18:18:30 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 18 Apr 2007 14:18:30 -0400 Subject: Fedora 7: SCIM Launch Problem Message-ID: <462660F6.2070909@redhat.com> April 16th there was a problematic comps change to F7 that necessitated associated other changes. FC6 and RHEL5 Behavior ====================== - scim packages were installed only if you chose languages that need it during install, or used groupinstall on a language. - If scim is installed, it automatically runs in the desktop of any language. - Enabled-by-default is potentially annoying to non-SCIM users. However, since it is not installed by default, those users did not complain so much. Users who didn't want it were told to uninstall it (which matches Windows and Mac behavior.) - im-chooser provided a way for the user to override the system's setting, to disable SCIM, or choose a different IM software for that user's desktop. Yesterday's Change ================== https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229742 We attempted to solve this rare groupremove problem by making SCIM install with the base-x group. This means that *ALL* Fedora desktop installations will have SCIM both installed and running. Due to the enabled-by-default behavior, SCIM annoys non-SCIM users who accidentally hit SCIM hotkeys, popping up the language bar or inputting unwanted characters. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235435 In an attempt to mitigate this enabled-by-default behavior, this change was hastily made without being thoroughly thought through. It disables the SCIM activation hotkey (CTRL-Space) if you login to a new user profile for the first time with a language that doesn't normally need SCIM. Disabling the hotkey by default is problematic: =============================================== - This creates inconsistent behavior between SCIM user profiles created at different times, depending on what locale and version of Fedora was running at the time. (Source of support and debugging confusion.) - This forces certain users to use a confusingly disjoint configuration within SCIM Setup, which is separate from im-chooser. (User confusion) - This still has an unnecessary memory footprint for users who absolutely never need SCIM. Solution ======== Jeremy Katz, the RH Desktop team and I have agreed upon the following. 1) Undo the hack made in Bug #235435. 2) Change SCIM's automatic launching to be locale specific. For example, Asian languages are in a SCIM automatic list, so launch automatically in those languages. Do not launch SCIM automatically in other languages. 3) Modify im-chooser to allow the user to override the automatic SCIM launch behavior. im-chooser should offer something like: * Always Use [SCIM] * Follow the system-wide configuration [SCIM] * Never use input methods "Follow the system-wide configuration [SCIM]" would be the default for all users. The user can then choose to explicitly override, to enable or disable input methods independently of their locale. Can we please implement this before Fedora 7? The SCIM running by default in all desktop languages is unacceptable, and the hack in Bug #235435 confuses the issue, hiding the real problem. We are willing to be flexible during the freeze to fix this. Warren Togami wtogami at redhat.com From peter at thecodergeek.com Wed Apr 18 18:28:17 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 18 Apr 2007 11:28:17 -0700 Subject: Father In-Reply-To: <46265BC5.6000100@hhs.nl> References: <46261B8A.9090409@hhs.nl> <1176905137.3360.2.camel@tuxhugs> <46265BC5.6000100@hhs.nl> Message-ID: <1176920897.28087.1.camel@tuxhugs> On Wed, 2007-04-18 at 19:56 +0200, Hans de Goede wrote: > We were at the doctors for a regular checkup and there was a book with possible > childrens names there, that is where the name Eowyn comes from, and according > to that same book (and other sources) the name Eowyn indeed comes from Tolkien. It's a beautiful name. Congrats, and warm wishes. :-) -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 martin.sourada at seznam.cz Wed Apr 18 18:34:48 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 18 Apr 2007 20:34:48 +0200 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: <462664C8.8060504@seznam.cz> Hello Hans, Congrats. Accept my best wishes for you and your newly expanded family. :-) Martin P.S. You've picked nice name :-) Hans de Goede napsal(a): > Hi all, > > This morning, 10.35 CET, I've become the father of a daughter for the > second time. Her names is Eowyn and she ways 3.5 Kg. > > Both mother and daughter are well. > > Regards, > > Hans > > > p.s. > > I'm sure you'll all understand that this means that the coming time I > might be a little less responsive to bugreports / reviews / mails then I > normally am. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From katzj at redhat.com Wed Apr 18 18:37:57 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 18 Apr 2007 14:37:57 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <462660F6.2070909@redhat.com> References: <462660F6.2070909@redhat.com> Message-ID: <1176921477.15165.38.camel@aglarond.local> On Wed, 2007-04-18 at 14:18 -0400, Warren Togami wrote: > Yesterday's Change > ================== > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229742 > We attempted to solve this rare groupremove problem by making SCIM > install with the base-x group. This means that *ALL* Fedora desktop > installations will have SCIM both installed and running. Note that the live CD for Fedora 7 has been including SCIM in all cases since day 1. So this is just increasing our overall consistency in addition to fixing the groupremove case. [snip] > Solution > ======== > Jeremy Katz, the RH Desktop team and I have agreed upon the following. > > 1) Undo the hack made in Bug #235435. Should be straight-forward... > 2) Change SCIM's automatic launching to be locale specific. For > example, Asian languages are in a SCIM automatic list, so launch > automatically in those languages. Do not launch SCIM automatically in > other languages. Also should be straight-forward. > 3) Modify im-chooser to allow the user to override the automatic SCIM > launch behavior. im-chooser should offer something like: > * Always Use [SCIM] > * Follow the system-wide configuration [SCIM] > * Never use input methods I would guess that this is pretty easy to do? > Can we please implement this before Fedora 7? The SCIM running by > default in all desktop languages is unacceptable, and the hack in Bug > #235435 confuses the issue, hiding the real problem. > > We are willing to be flexible during the freeze to fix this. How much can we get in the next day or two so that we can also get eyes on the change with test4? Can we at least get the first two and the backend of the third (ie, not necessarily the UI but the setting and a simple description of how to manually do it)? Jeremy From peter at thecodergeek.com Wed Apr 18 18:37:35 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 18 Apr 2007 11:37:35 -0700 Subject: broken deps outside of packagers control In-Reply-To: <46265C68.7050902@hhs.nl> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> Message-ID: <1176921455.28087.7.camel@tuxhugs> On Wed, 2007-04-18 at 19:59 +0200, Hans de Goede wrote: > In that case can gnumeric please be blacklisted, and the i386 version removed > from the x86_64 repo? > > Thanks & regards, > > Hans Unfortunately, it's not that simple - gnumeric-devel is a proper subpackage of gnumeric, and as a good -devel subpackage, it properly requires its base package - which means you'll have gnumeric installed twice in a multilib setup, for each of these two arches. A potential way to ease this is to split out a -libs subpackage which contains the shared libraries (which are the things a -devel package really needs), then make both the base package and the -devel subpackage depend on it via a fully-versioned Requires tag. (See, for example, my recent split of the openbox packaging.) Then, gnumeric and gnumeric-devel would depend on gnumeric-libs, but you would have only one instance of gnumeric installed (for the parent arch). Hope that helps. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 wtogami at redhat.com Wed Apr 18 18:40:57 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 18 Apr 2007 14:40:57 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <1176921477.15165.38.camel@aglarond.local> References: <462660F6.2070909@redhat.com> <1176921477.15165.38.camel@aglarond.local> Message-ID: <46266639.8010103@redhat.com> Jeremy Katz wrote: >> 3) Modify im-chooser to allow the user to override the automatic SCIM >> launch behavior. im-chooser should offer something like: >> * Always Use [SCIM] >> * Follow the system-wide configuration [SCIM] >> * Never use input methods > > I would guess that this is pretty easy to do? With the exception of translations, yes. > >> Can we please implement this before Fedora 7? The SCIM running by >> default in all desktop languages is unacceptable, and the hack in Bug >> #235435 confuses the issue, hiding the real problem. >> >> We are willing to be flexible during the freeze to fix this. > > How much can we get in the next day or two so that we can also get eyes > on the change with test4? Can we at least get the first two and the > backend of the third (ie, not necessarily the UI but the setting and a > simple description of how to manually do it)? > > Jeremy I'm looking into this myself right now, then I will hand it to eng-i18n to hopefully finish it during our night. Warren From notting at redhat.com Wed Apr 18 18:43:48 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 Apr 2007 14:43:48 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <46266639.8010103@redhat.com> References: <462660F6.2070909@redhat.com> <1176921477.15165.38.camel@aglarond.local> <46266639.8010103@redhat.com> Message-ID: <20070418184348.GA20047@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > >>3) Modify im-chooser to allow the user to override the automatic SCIM > >>launch behavior. im-chooser should offer something like: > >> * Always Use [SCIM] > >> * Follow the system-wide configuration [SCIM] > >> * Never use input methods > > > >I would guess that this is pretty easy to do? > > With the exception of translations, yes. The issue I see here is that 'follow the system-wide configuration' is not too informative to the user - what is the system-wide config? How should they know that? Would "Only use SCIM for non-Latin locales" be better? Something else? Bill From wtogami at redhat.com Wed Apr 18 18:48:02 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 18 Apr 2007 14:48:02 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <20070418184348.GA20047@nostromo.devel.redhat.com> References: <462660F6.2070909@redhat.com> <1176921477.15165.38.camel@aglarond.local> <46266639.8010103@redhat.com> <20070418184348.GA20047@nostromo.devel.redhat.com> Message-ID: <462667E2.6010600@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >>>> 3) Modify im-chooser to allow the user to override the automatic SCIM >>>> launch behavior. im-chooser should offer something like: >>>> * Always Use [SCIM] >>>> * Follow the system-wide configuration [SCIM] >>>> * Never use input methods >>> I would guess that this is pretty easy to do? >> With the exception of translations, yes. > > The issue I see here is that 'follow the system-wide configuration' is not > too informative to the user - what is the system-wide config? How should > they know that? > > Would "Only use SCIM for non-Latin locales" be better? Something else? > I agree "Follow the system-wide configuration" is confusing and non-ideal. I would have chosen something closer to "Automatic" myself. But changing the label of that now would require more disruptive translation changes too... Warren From chris.stone at gmail.com Wed Apr 18 19:02:13 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Apr 2007 12:02:13 -0700 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: On 4/18/07, Hans de Goede wrote: > This morning, 10.35 CET, I've become the father of a daughter for the second > time. Her names is Eowyn and she ways 3.5 Kg. Congratulations on your new little princess! From chris.stone at gmail.com Wed Apr 18 19:13:28 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Apr 2007 12:13:28 -0700 Subject: broken deps outside of packagers control In-Reply-To: <1176921455.28087.7.camel@tuxhugs> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> Message-ID: On 4/18/07, Peter Gordon wrote: > On Wed, 2007-04-18 at 19:59 +0200, Hans de Goede wrote: > > In that case can gnumeric please be blacklisted, and the i386 version removed > > from the x86_64 repo? > > > > Thanks & regards, > > > > Hans > > Unfortunately, it's not that simple - gnumeric-devel is a proper > subpackage of gnumeric, and as a good -devel subpackage, it properly > requires its base package - which means you'll have gnumeric installed > twice in a multilib setup, for each of these two arches. > > A potential way to ease this is to split out a -libs subpackage which > contains the shared libraries (which are the things a -devel package > really needs), then make both the base package and the -devel subpackage > depend on it via a fully-versioned Requires tag. (See, for example, my > recent split of the openbox packaging.) > > Then, gnumeric and gnumeric-devel would depend on gnumeric-libs, but you > would have only one instance of gnumeric installed (for the parent > arch). > > Hope that helps. Hans does this sound good to you? My pygame package has the same fate and so far the best solution presented to me was to just remove the devel package and bundle everything in a single package (because no one ever uses pygame-devel presumably). This sounds like a better solution to me however. From laroche at redhat.com Wed Apr 18 19:16:55 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 18 Apr 2007 21:16:55 +0200 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: <20070418191655.GA4541@dudweiler.stuttgart.redhat.com> On Wed, Apr 18, 2007 at 03:22:18PM +0200, Hans de Goede wrote: > Hi all, > > This morning, 10.35 CET, I've become the father of a daughter for the > second time. Her names is Eowyn and she ways 3.5 Kg. > > Both mother and daughter are well. > > Regards, Best wishes and happy family live for all of you. regards, Florian La Roche > > Hans > > > p.s. > > I'm sure you'll all understand that this means that the coming time I might > be a little less responsive to bugreports / reviews / mails then I normally > am. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From sundaram at fedoraproject.org Wed Apr 18 19:20:02 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Apr 2007 00:50:02 +0530 Subject: What happened to Fedora Tracker? In-Reply-To: <29fee02b0704160044p5a87ca66g295ee34e65d97943@mail.gmail.com> References: <29fee02b0704160044p5a87ca66g295ee34e65d97943@mail.gmail.com> Message-ID: <46266F62.7040905@fedoraproject.org> Andrea Musuruane wrote: > Hi, > does someone know what happened to Fedora Tracker? > > http://fedoratracker.org/ > http://www.redhat.com/archives/fedora-devel-list/2007-January/msg01198.html Rahul From chris.stone at gmail.com Wed Apr 18 19:40:09 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 18 Apr 2007 12:40:09 -0700 Subject: broken deps outside of packagers control In-Reply-To: References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> Message-ID: On 4/18/07, Christopher Stone wrote: > On 4/18/07, Peter Gordon wrote: > > On Wed, 2007-04-18 at 19:59 +0200, Hans de Goede wrote: > > > In that case can gnumeric please be blacklisted, and the i386 version removed > > > from the x86_64 repo? > > > > > > Thanks & regards, > > > > > > Hans > > > > Unfortunately, it's not that simple - gnumeric-devel is a proper > > subpackage of gnumeric, and as a good -devel subpackage, it properly > > requires its base package - which means you'll have gnumeric installed > > twice in a multilib setup, for each of these two arches. > > > > A potential way to ease this is to split out a -libs subpackage which > > contains the shared libraries (which are the things a -devel package > > really needs), then make both the base package and the -devel subpackage > > depend on it via a fully-versioned Requires tag. (See, for example, my > > recent split of the openbox packaging.) > > > > Then, gnumeric and gnumeric-devel would depend on gnumeric-libs, but you > > would have only one instance of gnumeric installed (for the parent > > arch). > > > > Hope that helps. > > Hans does this sound good to you? My pygame package has the same fate > and so far the best solution presented to me was to just remove the > devel package and bundle everything in a single package (because no > one ever uses pygame-devel presumably). This sounds like a better > solution to me however. > Well I dug up the thread on pygame, I guess Michael is correct in my case[1], which reminds me I still need to fix up some dependencies for Fedora 7 on that package... [1] https://www.redhat.com/archives/fedora-extras-list/2006-December/msg00247.html From peter at thecodergeek.com Wed Apr 18 18:40:46 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 18 Apr 2007 11:40:46 -0700 Subject: broken deps outside of packagers control In-Reply-To: <46265C68.7050902@hhs.nl> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> Message-ID: <1176921455.28087.7.camel@tuxhugs> On Wed, 2007-04-18 at 19:59 +0200, Hans de Goede wrote: > In that case can gnumeric please be blacklisted, and the i386 version removed > from the x86_64 repo? > > Thanks & regards, > > Hans Unfortunately, it's not that simple - gnumeric-devel is a proper subpackage of gnumeric, and as a good -devel subpackage, it properly requires its base package - which means you'll have gnumeric installed twice in a multilib setup, for each of these two arches. A potential way to ease this is to split out a -libs subpackage which contains the shared libraries (which are the things a -devel package really needs), then make both the base package and the -devel subpackage depend on it via a fully-versioned Requires tag. (See, for example, my recent split of the openbox packaging.) Then, gnumeric and gnumeric-devel would depend on gnumeric-libs, but you would have only one instance of gnumeric installed (for the parent arch). Hope that helps. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 bpepple at fedoraproject.org Wed Apr 18 21:05:16 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Apr 2007 17:05:16 -0400 Subject: Plan for tomorrows (20070418) FESCO meeting Message-ID: <1176930316.7873.7.camel@lincoln> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old disttag - jwb /topic FESCO-Meeting -- MISC -- comps process - notting /topic FESCO-Meeting -- MISC -- Upcoming FESCo election planning - bpepple /topic FESCO-Meeting -- MISC -- FESCo Future Responsibilities /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- EPEL /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora Extras" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 musuruan at gmail.com Wed Apr 18 21:13:02 2007 From: musuruan at gmail.com (Andrea Musuruane) Date: Wed, 18 Apr 2007 23:13:02 +0200 Subject: Father In-Reply-To: <46261B8A.9090409@hhs.nl> References: <46261B8A.9090409@hhs.nl> Message-ID: <1176930782.5284.3.camel@localhost.localdomain> Il giorno mer, 18/04/2007 alle 15.22 +0200, Hans de Goede ha scritto: > Hi all, > > This morning, 10.35 CET, I've become the father of a daughter for the second > time. Her names is Eowyn and she ways 3.5 Kg. > > Both mother and daughter are well. > > Regards, > > Hans Congratulations! Andrea. From sundaram at fedoraproject.org Wed Apr 18 21:35:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 19 Apr 2007 03:05:48 +0530 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <1176930316.7873.7.camel@lincoln> References: <1176930316.7873.7.camel@lincoln> Message-ID: <46268F34.5090809@fedoraproject.org> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, > rdieter, tibbs, scop > > /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old > disttag - jwb > > /topic FESCO-Meeting -- MISC -- comps process - notting > > /topic FESCO-Meeting -- MISC -- Upcoming FESCo election planning - > bpepple > > /topic FESCO-Meeting -- MISC -- FESCo Future Responsibilities > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb > > /topic FESCO-Meeting -- EPEL > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora Extras" phase. You might want to drop the "Extras" here and from the template which you are using. Rahul From bpepple at fedoraproject.org Wed Apr 18 21:45:40 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 18 Apr 2007 17:45:40 -0400 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <46268F34.5090809@fedoraproject.org> References: <1176930316.7873.7.camel@lincoln> <46268F34.5090809@fedoraproject.org> Message-ID: <1176932740.7873.13.camel@lincoln> On Thu, 2007-04-19 at 03:05 +0530, Rahul Sundaram wrote: > Brian Pepple wrote: > > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora Extras" phase. > > You might want to drop the "Extras" here and from the template which you > are using. Your right, thanks for the catch. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 wtogami at redhat.com Wed Apr 18 23:10:20 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 18 Apr 2007 19:10:20 -0400 Subject: IM Chooser Design Re: Fedora 7: SCIM Launch Problem In-Reply-To: <462667E2.6010600@redhat.com> References: <462660F6.2070909@redhat.com> <1176921477.15165.38.camel@aglarond.local> <46266639.8010103@redhat.com> <20070418184348.GA20047@nostromo.devel.redhat.com> <462667E2.6010600@redhat.com> Message-ID: <4626A55C.6040404@redhat.com> http://togami.com/~warren/archive/2007/im-chooser.png Existing im-chooser interface. Maureen Duffy (our expert UI engineer) and I spent some time in front of a whiteboard. We came up with this design to improve im-chooser to support the desired IM behavior. More work on the backend X init scripts need to be done. I am further examining those next. http://togami.com/~warren/archive/2007/im-chooser-design.jpg The labels could change, but here are some design consideration notes. Radial Buttons: Option 1) Automatic and tells you which it is for your language Option 2) Enable and choose a specific IM Option 3) Disable IM - There is an explicit option for enabling and disabling, separate from the automatic option. This makes it very clear that choosing and disabling is different from the automatic behavior. - The automatic option plainly tells the user what the automatic IM for their session locale is. "None" would be displayed for English for example. - "Locale" is not used in the label because it is too technical. "Language" is close enough in meaning and easier to understand. - "Do not use" instead of "Disable", because the latter could be scary to users who don't know what Input Methods are. "Do not use" doesn't sound like you will break your keyboard. - The legacy radial button was confusing, so it is eliminated. If legacy software like kinput2 is installed, "Legacy XIM" could appear in the drop-down combo box instead. Warren Togami wtogami at redhat.com From mclasen at redhat.com Thu Apr 19 03:20:56 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 18 Apr 2007 23:20:56 -0400 Subject: IM Chooser Design Re: Fedora 7: SCIM Launch Problem In-Reply-To: <4626A55C.6040404@redhat.com> References: <462660F6.2070909@redhat.com> <1176921477.15165.38.camel@aglarond.local> <46266639.8010103@redhat.com> <20070418184348.GA20047@nostromo.devel.redhat.com> <462667E2.6010600@redhat.com> <4626A55C.6040404@redhat.com> Message-ID: <1176952856.2985.2.camel@localhost.localdomain> On Wed, 2007-04-18 at 19:10 -0400, Warren Togami wrote: > http://togami.com/~warren/archive/2007/im-chooser.png > Existing im-chooser interface. > > Maureen Duffy (our expert UI engineer) and I spent some time in front of > a whiteboard. We came up with this design to improve im-chooser to > support the desired IM behavior. More work on the backend X init > scripts need to be done. I am further examining those next. > > http://togami.com/~warren/archive/2007/im-chooser-design.jpg > The labels could change, but here are some design consideration notes. > > Radial Buttons: > Option 1) Automatic and tells you which it is for your language > Option 2) Enable and choose a specific IM > Option 3) Disable IM > Looks reasonable to me. It would probably be nicer if we could get rid of the "custom" term in the second option. You used "specific" in your description above. From fedora at leemhuis.info Thu Apr 19 05:10:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Apr 2007 07:10:26 +0200 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <1176930316.7873.7.camel@lincoln> References: <1176930316.7873.7.camel@lincoln> Message-ID: <4626F9C2.5030509@leemhuis.info> On 18.04.2007 23:05, Brian Pepple wrote: > > /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old > disttag - jwb > Something related to this (mentioned on FAB-list 24 hours ago, but didn't get any replies) to fix the problem in F8 and later: Why don't we just expand the disttag to something else without the "fcn" in it in the devel branch? Then we don't have run into the "package disttag doesn't match the release it is shipped in" problem when a package is not rebuild during a devel cycle. A simple ".1" maybe -- that should make everybody happy afaics: [thl at thl tmp]$ # this is how we do it right now: [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.fc7 0:1.0-5.fc7 is newer [thl at thl tmp]$ # why not do it like this: [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.1 0:1.0-5.1 is newer Or am I or rpmdev-vercmp missing something here? /me always gets a bit confused when it comes to letters in %{release} BTW, sure, the changelog entry and the actual release won't match fully this way, but that's the same with disttags that expand to ".fcX" . CU thl From mclasen at redhat.com Thu Apr 19 05:14:10 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 19 Apr 2007 01:14:10 -0400 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <4626F9C2.5030509@leemhuis.info> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> Message-ID: <1176959650.2985.5.camel@localhost.localdomain> On Thu, 2007-04-19 at 07:10 +0200, Thorsten Leemhuis wrote: > > On 18.04.2007 23:05, Brian Pepple wrote: > > > > /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old > > disttag - jwb > > > > Something related to this (mentioned on FAB-list 24 hours ago, but > didn't get any replies) to fix the problem in F8 and later: > > Why don't we just expand the disttag to something else without the > "fcn" in it in the devel branch? Then we don't have run into the > "package disttag doesn't match the release it is shipped in" problem > when a package is not rebuild during a devel cycle. A simple ".1" maybe > -- that should make everybody happy afaics: How would a mixture of .1 and .fc6 in the released fc7 make everybody happier than a mixture of .1 and .fc7 ? Or does the proposal include a mass rebuild on day zero to replace all .1 by .fc7 ? From paul at xelerance.com Thu Apr 19 05:20:02 2007 From: paul at xelerance.com (Paul Wouters) Date: Thu, 19 Apr 2007 07:20:02 +0200 (CEST) Subject: Oprhaning driftnet In-Reply-To: <1176905433.32379.27.camel@cookie.hadess.net> References: <1176905433.32379.27.camel@cookie.hadess.net> Message-ID: On Wed, 18 Apr 2007, Bastien Nocera wrote: > I'm not using driftnet at all, and wanted to orphan it. > The only opened bug is at: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201412 > > And can be fixed by using the gtk2 port used in the debian package, > instead of mine. I'll take it if it is still unclaimed. Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From j.w.r.degoede at hhs.nl Thu Apr 19 05:39:10 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 19 Apr 2007 07:39:10 +0200 Subject: broken deps outside of packagers control In-Reply-To: References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> Message-ID: <4627007E.2090007@hhs.nl> Christopher Stone wrote: > On 4/18/07, Peter Gordon wrote: >> On Wed, 2007-04-18 at 19:59 +0200, Hans de Goede wrote: >> > In that case can gnumeric please be blacklisted, and the i386 >> version removed >> > from the x86_64 repo? >> > >> > Thanks & regards, >> > >> > Hans >> >> Unfortunately, it's not that simple - gnumeric-devel is a proper >> subpackage of gnumeric, and as a good -devel subpackage, it properly >> requires its base package - which means you'll have gnumeric installed >> twice in a multilib setup, for each of these two arches. >> >> A potential way to ease this is to split out a -libs subpackage which >> contains the shared libraries (which are the things a -devel package >> really needs), then make both the base package and the -devel subpackage >> depend on it via a fully-versioned Requires tag. (See, for example, my >> recent split of the openbox packaging.) >> >> Then, gnumeric and gnumeric-devel would depend on gnumeric-libs, but you >> would have only one instance of gnumeric installed (for the parent >> arch). >> >> Hope that helps. > > Hans does this sound good to you? My pygame package has the same fate > and so far the best solution presented to me was to just remove the > devel package and bundle everything in a single package (because no > one ever uses pygame-devel presumably). This sounds like a better > solution to me however. > No this sounds like a BAD solution to me. We are going to have this problem for every non noarch perl / python / ruby / xxx package that happens to split of a -devel package (for example because of .pc files). The proper solution is to either: 1) make the push script smarter 2) use a blacklist Also notice that gnumeric-devel is not a full devel package, it contains a .so symlink but no header files as libspreadsheet.so.xxx so far is intended for use by gnumeric only. Besides that it contains an .idl file. I've always been amazed about the split-off of a seperate devel package for these 2 files (1 symlink and file actually) but that is how I inhereted things from core. Notice that fixing this won't help as the #@$%^#@ push-script will also put .i386 packages in the x86_64 tree if they have a virtual -devel provides, and if I nuke the -devel package, the main package will provide -devel for those depending on it. Now in the case of gnumeric probably nothing is depending on the -devel, so I could just nuke the -devel without adding the virtual provides. But I _refuse_ todo this as this is bad packaging. Once a package is out there people should be able to count on it offering a consistent "interface". Even more important I _refuse_ todo this because its the push-script that needs fixing, not gnumeric. Regards, Hans From fedora at leemhuis.info Thu Apr 19 05:25:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Apr 2007 07:25:38 +0200 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <1176959650.2985.5.camel@localhost.localdomain> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> <1176959650.2985.5.camel@localhost.localdomain> Message-ID: <4626FD52.2020302@leemhuis.info> On 19.04.2007 07:14, Matthias Clasen wrote: > On Thu, 2007-04-19 at 07:10 +0200, Thorsten Leemhuis wrote: >> On 18.04.2007 23:05, Brian Pepple wrote: >> > >>> /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old >>> disttag - jwb >>> >> Something related to this (mentioned on FAB-list 24 hours ago, but >> didn't get any replies) to fix the problem in F8 and later: >> >> Why don't we just expand the disttag to something else without the >> "fcn" in it in the devel branch? Then we don't have run into the >> "package disttag doesn't match the release it is shipped in" problem >> when a package is not rebuild during a devel cycle. A simple ".1" maybe >> -- that should make everybody happy afaics: > > How would a mixture of .1 and .fc6 in the released fc7 make everybody > happier than a mixture of .1 and .fc7 ? "to fix the problem in F8 and later" -- IOW: I think this change should be done after F7 was branched, to make this problem go away over time. For FC7 I think it's far to late for changes like this or mass-rebuilds to get rid of the fc6 in the devel branch. > Or does the proposal include a > mass rebuild on day zero to replace all .1 by .fc7 ? You mean rebuild everything in devel after F7 is out? Could be done if we want to, but I suppose its not worth the trouble: the problem will vanish on it's own mostly by F8; maybe we'll do a mass rebuild for F8 anyway if the toolchain should change. OIOW: I'd say we simply change to what the distttag expands right after F7 was branched, and then look at the repos by F8-test1 or test2 and decide then what to do. CU thl From buildsys at fedoraproject.org Thu Apr 19 06:22:52 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 19 Apr 2007 02:22:52 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-19 Message-ID: <20070419062252.95765152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) jonathansteffan AT gmail.com: plone FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) zope FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) ---------------------------------------------------------------------- gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) plone: jonathansteffan AT gmail.com FE5 > FE7 (0:2.5.2-1.fc5 > 0:2.5.1-3.fc7) FE6 > FE7 (0:2.5.2-1.fc6 > 0:2.5.1-3.fc7) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) zope: jonathansteffan AT gmail.com FE5 > FE7 (0:2.9.7-1.fc5 > 0:2.9.4-2.fc6) FE6 > FE7 (0:2.9.7-1.fc6 > 0:2.9.4-2.fc6) From bugs.michael at gmx.net Thu Apr 19 08:22:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Apr 2007 10:22:57 +0200 Subject: broken deps outside of packagers control In-Reply-To: <4627007E.2090007@hhs.nl> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> Message-ID: <20070419102257.04004858.bugs.michael@gmx.net> On Thu, 19 Apr 2007 07:39:10 +0200, Hans de Goede wrote: > No this sounds like a BAD solution to me. We are going to have this problem for > every non noarch perl / python / ruby / xxx package that happens to split of a > -devel package (for example because of .pc files). The proper solution is to > either: > 1) make the push script smarter > 2) use a blacklist > > Also notice that gnumeric-devel is not a full devel package, it contains a .so > symlink but no header files as libspreadsheet.so.xxx so far is intended for use > by gnumeric only. Besides that it contains an .idl file. I've always been > amazed about the split-off of a seperate devel package for these 2 files (1 > symlink and file actually) but that is how I inhereted things from core. Highly questionable packaging, and with a brief look I also find issues: /usr/lib/bonobo/servers/GNOME_Gnumeric.server It points to a non-existant /usr/libexec/gnumeric-component executable as well as an unexpanded @prefix@/bin/gnumeric Splitting off the single .idl file isn't justified. The idl file itself builds fine (whether it would work at run-time is another question), but currently, the Gnumeric component is broken. The *.so symlink is of no use without any API for the library. The -devel package need not require the main package. > Notice that fixing this won't help as the #@$%^#@ push-script Stay nice, please. The Fedora community should stay a friendly place. > will also put > .i386 packages in the x86_64 tree if they have a virtual -devel provides, and > if I nuke the -devel package, the main package will provide -devel for those > depending on it. Nothing wrong about that. Virtual packages are not hidden. They can be used in dependencies and are visible to users, too. > Now in the case of gnumeric probably nothing is depending on the -devel, so I > could just nuke the -devel without adding the virtual provides. But I _refuse_ > todo this as this is bad packaging. Once a package is out there people should > be able to count on it offering a consistent "interface". Even more important I > _refuse_ todo this because its the push-script that needs fixing, not gnumeric. > No. The pushscript makes available the i386 development packages for x86_64, so you can develop for i386 on x86_64. From bugs.michael at gmx.net Thu Apr 19 08:47:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Apr 2007 10:47:50 +0200 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <4626F9C2.5030509@leemhuis.info> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> Message-ID: <20070419104750.505f2f8d.bugs.michael@gmx.net> On Thu, 19 Apr 2007 07:10:26 +0200, Thorsten Leemhuis wrote: > > > On 18.04.2007 23:05, Brian Pepple wrote: > > > > /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old > > disttag - jwb > > > > Something related to this (mentioned on FAB-list 24 hours ago, but > didn't get any replies) to fix the problem in F8 and later: > > Why don't we just expand the disttag to something else without the > "fcn" in it in the devel branch? Then we don't have run into the > "package disttag doesn't match the release it is shipped in" problem > when a package is not rebuild during a devel cycle. A simple ".1" maybe > -- that should make everybody happy afaics: > > [thl at thl tmp]$ # this is how we do it right now: > [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.fc7 > 0:1.0-5.fc7 is newer > [thl at thl tmp]$ # why not do it like this: > [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.1 > 0:1.0-5.1 is newer > > Or am I or rpmdev-vercmp missing something here? You are missing the rebuild. Assume we create the FC-7 branch from current devel and target Fedora 8 in devel. Then devel starts with the packages that have a dist tag .fc7 (or older) or no dist tag. All the packages need at least one rebuild to change the package release field. Only packages, which are not rebuilt, keep their old Release. But builds in devel would get a .fc8 dist tag, so when rebuilding a package why jump to .1 instead of .fc8? If you want to rebuild all packages with a changed %dist and without modifying the spec files to bump Release, the plan is flawed. "1" > "f", hence "1" is newer than all fcN dist tags, okay, but you only get an upgrade path from Fedora <= 7 to "1", since for Fedora 9 you would need to jump from "1" to "2" for any rebuilds to be newer than Fedora 8 again. So, conclusively, this proposal only shoves the problem under the carpet. ;) From bnocera at redhat.com Thu Apr 19 08:49:38 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 19 Apr 2007 09:49:38 +0100 Subject: Oprhaning driftnet In-Reply-To: References: <1176905433.32379.27.camel@cookie.hadess.net> Message-ID: <1176972578.32379.43.camel@cookie.hadess.net> On Thu, 2007-04-19 at 07:20 +0200, Paul Wouters wrote: > On Wed, 18 Apr 2007, Bastien Nocera wrote: > > > I'm not using driftnet at all, and wanted to orphan it. > > The only opened bug is at: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201412 > > > > And can be fixed by using the gtk2 port used in the debian package, > > instead of mine. > > I'll take it if it is still unclaimed. It's all yours :) From fedora at leemhuis.info Thu Apr 19 09:00:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Apr 2007 11:00:15 +0200 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <20070419104750.505f2f8d.bugs.michael@gmx.net> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> <20070419104750.505f2f8d.bugs.michael@gmx.net> Message-ID: <46272F9F.2030909@leemhuis.info> On 19.04.2007 10:47, Michael Schwendt wrote: > On Thu, 19 Apr 2007 07:10:26 +0200, Thorsten Leemhuis wrote: >> On 18.04.2007 23:05, Brian Pepple wrote: >>> /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old >>> disttag - jwb >> Something related to this (mentioned on FAB-list 24 hours ago, but >> didn't get any replies) to fix the problem in F8 and later: >> Why don't we just expand the disttag to something else without the >> "fcn" in it in the devel branch? Then we don't have run into the >> "package disttag doesn't match the release it is shipped in" problem >> when a package is not rebuild during a devel cycle. A simple ".1" maybe >> -- that should make everybody happy afaics: >> [thl at thl tmp]$ # this is how we do it right now: >> [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.fc7 >> 0:1.0-5.fc7 is newer >> [thl at thl tmp]$ # why not do it like this: >> [thl at thl tmp]$ rpmdev-vercmp 0 1.0 5.fc6 0 1.0 5.1 >> 0:1.0-5.1 is newer >> Or am I or rpmdev-vercmp missing something here? > You are missing the rebuild. I thought it wasn't needed to mention that, as a new distag of course are only picked on the next build. > Assume we create the FC-7 branch from current devel and target Fedora 8 in > devel. Then devel starts with the packages that have a dist tag .fc7 (or > older) or no dist tag. All the packages need at least one rebuild to > change the package release field. Sure. > Only packages, which are not rebuilt, > keep their old Release. But builds in devel would get a .fc8 dist tag, so > when rebuilding a package why jump to .1 instead of .fc8? Because we solve the problem in the *long term* once and for all. Example: - after F7 was branched change the disttag in devel to be ".1" - packages that get build afterwards pick it up - assume we have a mass-rebuild in F8 (we'll have one sooner or later in any case, so lets just assume F8 for now) - F8 gets released and no packages shipped with it have a disttag "fc8" now; new packages build after release get one, as that easier - F9 sees no mass rebuild; packages that were not rebuild during the devel cycle F8 -> F9 can stay as they are; F9 gets release and there are no packages with a ".fc8" in it, so we avoid the confusion we have now (that is: ship F7 with packages that have fc6 in ENVR) > If you want to rebuild all packages with a changed %dist and without > modifying the spec files to bump Release, the plan is flawed. "1" > "f", > hence "1" is newer than all fcN dist tags, okay, but you only get an > upgrade path from Fedora <= 7 to "1", since for Fedora 9 you would need to > jump from "1" to "2" for any rebuilds to be newer than Fedora 8 again. No, you don't need to jump from "1" to "2" -- packages that were not rebuild during that devel cycle simply stay as they are. Packages that got build due to updates will have the release-integer increased that's *before* the %{?dist} in the spec file. CU thl From bugs.michael at gmx.net Thu Apr 19 09:43:45 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Apr 2007 11:43:45 +0200 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <46272F9F.2030909@leemhuis.info> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> <20070419104750.505f2f8d.bugs.michael@gmx.net> <46272F9F.2030909@leemhuis.info> Message-ID: <20070419114345.064ff70e.bugs.michael@gmx.net> On Thu, 19 Apr 2007 11:00:15 +0200, Thorsten Leemhuis wrote: > > Only packages, which are not rebuilt, > > keep their old Release. But builds in devel would get a .fc8 dist tag, so > > when rebuilding a package why jump to .1 instead of .fc8? > > Because we solve the problem in the *long term* once and for all. It doesn't solve any real problem, since packages that would benefit from a verified rebuild (under consideration of build logs and testing) would now sit in the distribution as old builds with a "hidden" dist tag. It remains an attempt at hiding the dist tag (or the "fc" in it!) for a purely cosmetical reason. The dist tag does not guarantee that a pkg really works for a distribution. If packages from Fedora 6 work just fine in Fedora 7 and haven't changed since Fedora 6, that's fine. > Example: > > - after F7 was branched change the disttag in devel to be ".1" > - packages that get build afterwards pick it up > - assume we have a mass-rebuild in F8 (we'll have one sooner or later in > any case, so lets just assume F8 for now) > - F8 gets released and no packages shipped with it have a disttag "fc8" > now; new packages build after release get one, as that easier > - F9 sees no mass rebuild; packages that were not rebuild during the > devel cycle F8 -> F9 can stay as they are; F9 gets release and there are > no packages with a ".fc8" in it, so we avoid the confusion we have now > (that is: ship F7 with packages that have fc6 in ENVR) Yes, it hides/alters the dist tag for all packages that are (re)built during the next devel cycle. Those, that are rebuilt frequently, lose the "fc" in the dist tag and cannot get it back until a post-release update is built. And those, that are not rebuilt between dist releases, remain a [potential] problem. I'm not a fan of %dist (because of its side-effects in deps and changelogs), but playing tricks with dist tags makes it worse. Better would be a proper roadmap that requests package owners to prepare their packages for test1 (e.g.) and enforce an automated rebuild (with Release bump and changelog entry) if they don't meet the deadline. From jnovy at redhat.com Thu Apr 19 09:42:52 2007 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 19 Apr 2007 11:42:52 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2007-04-19 In-Reply-To: <20070419071006.14739.24035@extras64.linux.duke.edu> References: <20070419071006.14739.24035@extras64.linux.duke.edu> Message-ID: <1176975772.28550.15.camel@redhat.usu> Hi all, On Thu, 2007-04-19 at 07:10 +0000, Fedora Extras repoclosure wrote: > package: uqm - 0.6.2-1.fc7.i386 from fedora-extras-development-i386 > unresolved deps: > libmikmod.so.2 these packages need to be rebuilt because of the recent update of mikmod (increased libmikmod soname): uqm xmms stratagus tecnoballz gweled ClanLib fbg methane I rebuilt all of those successfully without any modification against the new libmikmod.so.3 locally. Only ClanLib06 may need some tune-ups. Thanks, Jindrich From fedora at leemhuis.info Thu Apr 19 10:17:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Apr 2007 12:17:58 +0200 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <20070419114345.064ff70e.bugs.michael@gmx.net> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> <20070419104750.505f2f8d.bugs.michael@gmx.net> <46272F9F.2030909@leemhuis.info> <20070419114345.064ff70e.bugs.michael@gmx.net> Message-ID: <462741D6.6090802@leemhuis.info> On 19.04.2007 11:43, Michael Schwendt wrote: > On Thu, 19 Apr 2007 11:00:15 +0200, Thorsten Leemhuis wrote: > >>> Only packages, which are not rebuilt, >>> keep their old Release. But builds in devel would get a .fc8 dist tag, so >>> when rebuilding a package why jump to .1 instead of .fc8? >> Because we solve the problem in the *long term* once and for all. > It doesn't solve any real problem, since packages that would benefit from > a verified rebuild (under consideration of build logs and testing) would > now sit in the distribution as old builds with a "hidden" dist tag. Well, that get into the well known "rebuild every package each devel cycle or not" debate. > It remains an attempt at hiding the dist tag (or the "fc" in it!) for a > purely cosmetical reason. Agreed. But that's what some people want: don't have a fc6 disttag in Fedora 7. > The dist tag does not guarantee that a pkg really works for a distribution. > If packages from Fedora 6 work just fine > in Fedora 7 and haven't changed since Fedora 6, that's fine. Agreed. >> Example: >> - after F7 was branched change the disttag in devel to be ".1" >> - packages that get build afterwards pick it up >> - assume we have a mass-rebuild in F8 (we'll have one sooner or later in >> any case, so lets just assume F8 for now) >> - F8 gets released and no packages shipped with it have a disttag "fc8" >> now; new packages build after release get one, as that easier >> - F9 sees no mass rebuild; packages that were not rebuild during the >> devel cycle F8 -> F9 can stay as they are; F9 gets release and there are >> no packages with a ".fc8" in it, so we avoid the confusion we have now >> (that is: ship F7 with packages that have fc6 in ENVR) > Yes, it hides/alters the dist tag for all packages that are (re)built > during the next devel cycle. Those, that are rebuilt frequently, lose the > "fc" in the dist tag and cannot get it back until a post-release update is > built. Yes. But where is the problem with that? > And those, that are not rebuilt between dist releases, remain a > [potential] problem. I'm not a fan of %dist (because of its side-effects > in deps and changelogs), but playing tricks with dist tags makes it worse. Well, that why I proposed it here, to get such opinions (even if I disagree with "makes it worse" in this case). > Better would be a proper roadmap that requests package owners to prepare > their packages for test1 (e.g.) and enforce an automated rebuild (with > Release bump and changelog entry) if they don't meet the deadline. Well, that again gets into the old "rebuild every package each devel cycle or not" debate. Maybe it would be helpful if FESCo answers this question sooner or later to get rid of that topic for the near future... Side note: I was on the "rebuild everything each devel cycle" side in the past, but during the mass rebuilds of FE[56] (that I in parts organized) I hit quite a opposition when proposing that on the list; I changed my mind due to that and think that the benefits of rebuilding everything each time is not worth the costs. CU thl From mclasen at redhat.com Thu Apr 19 13:52:50 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 19 Apr 2007 09:52:50 -0400 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <4626FD52.2020302@leemhuis.info> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> <1176959650.2985.5.camel@localhost.localdomain> <4626FD52.2020302@leemhuis.info> Message-ID: <1176990770.3941.1.camel@dhcp83-33.boston.redhat.com> On Thu, 2007-04-19 at 07:25 +0200, Thorsten Leemhuis wrote: > On 19.04.2007 07:14, Matthias Clasen wrote: > > On Thu, 2007-04-19 at 07:10 +0200, Thorsten Leemhuis wrote: > >> On 18.04.2007 23:05, Brian Pepple wrote: > >> > > >>> /topic FESCO-Meeting -- MISC -- Vote on rebuilding packages with old > >>> disttag - jwb > >>> > >> Something related to this (mentioned on FAB-list 24 hours ago, but > >> didn't get any replies) to fix the problem in F8 and later: > >> > >> Why don't we just expand the disttag to something else without the > >> "fcn" in it in the devel branch? Then we don't have run into the > >> "package disttag doesn't match the release it is shipped in" problem > >> when a package is not rebuild during a devel cycle. A simple ".1" maybe > >> -- that should make everybody happy afaics: > > > > How would a mixture of .1 and .fc6 in the released fc7 make everybody > > happier than a mixture of .1 and .fc7 ? Sorry, I meant .1/.fc6 vs .fc6/.fc7. > OIOW: I'd say we simply change to what the distttag expands right after > F7 was branched, and then look at the repos by F8-test1 or test2 and > decide then what to do. > I don't see any real problem solved here, only cosmetics. From j.w.r.degoede at hhs.nl Thu Apr 19 14:40:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 19 Apr 2007 16:40:48 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070419102257.04004858.bugs.michael@gmx.net> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> Message-ID: <46277F70.4010305@hhs.nl> Michael Schwendt wrote: > > No. The pushscript makes available the i386 development packages for > x86_64, so you can develop for i386 on x86_64. > And does this in a very stupid way, for some reason in your reply you didn't bother to react to this: --- No this sounds like a BAD solution to me. We are going to have this problem for every non noarch perl / python / ruby / xxx package that happens to split of a -devel package (for example because of .pc files). --- Where I was talking about the pygame-devel issue, simply putting all .i386 packages which have a -devel subpackage / provides in the x86_64 tree is wrong. You can dance around it all you will, but in the end it is still wrong . And until this gets fixed we will keep see breakage like the gnumeric one. I agree that the -devel subpackage of gnumeric is a strange beast and probably not necessary, but thats not the discussion here, thats merely a symptom. An other fine example is pygame. We do not want i386 library wrappers for python / perl / ruby / xxx to end up in x86_64, just because then happen to have a -devel suppackage for, for example, pkgconfig files. Regards, Hans From dominik at greysector.net Thu Apr 19 15:05:14 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 19 Apr 2007 17:05:14 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070419102257.04004858.bugs.michael@gmx.net> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> Message-ID: <20070419150514.GB29404@ryvius.pekin.waw.pl> On Thursday, 19 April 2007 at 10:22, Michael Schwendt wrote: > On Thu, 19 Apr 2007 07:39:10 +0200, Hans de Goede wrote: > > > No this sounds like a BAD solution to me. We are going to have this problem for > > every non noarch perl / python / ruby / xxx package that happens to split of a > > -devel package (for example because of .pc files). The proper solution is to > > either: > > 1) make the push script smarter > > 2) use a blacklist > > > > Also notice that gnumeric-devel is not a full devel package, it contains a .so > > symlink but no header files as libspreadsheet.so.xxx so far is intended for use > > by gnumeric only. Besides that it contains an .idl file. I've always been > > amazed about the split-off of a seperate devel package for these 2 files (1 > > symlink and file actually) but that is how I inhereted things from core. > > Highly questionable packaging, and with a brief look I also find > issues: Is gg2-devel "highly questionable packaging" as well? gg2-libs depends on libperl.so (for perl scripting support) and there's no way around it. I don't want to disable perl scripting support. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bugs.michael at gmx.net Thu Apr 19 15:25:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Apr 2007 17:25:37 +0200 Subject: broken deps outside of packagers control In-Reply-To: <46277F70.4010305@hhs.nl> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> Message-ID: <20070419172537.d9cd60a9.bugs.michael@gmx.net> On Thu, 19 Apr 2007 16:40:48 +0200, Hans de Goede wrote: > Michael Schwendt wrote: > > > > No. The pushscript makes available the i386 development packages for > > x86_64, so you can develop for i386 on x86_64. > > > > And does this in a very stupid way, for some reason in your reply you didn't > bother to react to this: What is stupid? > --- > > No this sounds like a BAD solution to me. We are going to have this problem for > every non noarch perl / python / ruby / xxx package that happens to split of a > -devel package (for example because of .pc files). > > --- > > Where I was talking about the pygame-devel issue, pygame-devel is gone as it was broken. It required the main package without reason, and the main package required 32-bit Python which is not available for x86_64. The alternative would have been to blacklist pygame-devel. > simply putting all .i386 > packages which have a -devel subpackage / provides in the x86_64 tree is wrong. > Stupid. Wrong. Why? White-list, black-list, what do you refuse to understand? IMO, the gnumeric-devel package is broken and should be eliminated. It would not be the first -devel package which should never have been published. From bugs.michael at gmx.net Thu Apr 19 15:45:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Apr 2007 17:45:09 +0200 Subject: Plan for tomorrows (20070418) FESCO meeting In-Reply-To: <462741D6.6090802@leemhuis.info> References: <1176930316.7873.7.camel@lincoln> <4626F9C2.5030509@leemhuis.info> <20070419104750.505f2f8d.bugs.michael@gmx.net> <46272F9F.2030909@leemhuis.info> <20070419114345.064ff70e.bugs.michael@gmx.net> <462741D6.6090802@leemhuis.info> Message-ID: <20070419174509.3440f032.bugs.michael@gmx.net> On Thu, 19 Apr 2007 12:17:58 +0200, Thorsten Leemhuis wrote: > >> Example: > >> - after F7 was branched change the disttag in devel to be ".1" > >> - packages that get build afterwards pick it up > >> - assume we have a mass-rebuild in F8 (we'll have one sooner or later in > >> any case, so lets just assume F8 for now) > >> - F8 gets released and no packages shipped with it have a disttag "fc8" > >> now; new packages build after release get one, as that easier > >> - F9 sees no mass rebuild; packages that were not rebuild during the > >> devel cycle F8 -> F9 can stay as they are; F9 gets release and there are > >> no packages with a ".fc8" in it, so we avoid the confusion we have now > >> (that is: ship F7 with packages that have fc6 in ENVR) > > Yes, it hides/alters the dist tag for all packages that are (re)built > > during the next devel cycle. Those, that are rebuilt frequently, lose the > > "fc" in the dist tag and cannot get it back until a post-release update is > > built. > > Yes. But where is the problem with that? Well, on one hand, .fc6 dist tags in Fedora 7 are considered bad and confusing [*], and on the other hand, you eradicate "fc" in dist tags of packages, which are updated during the devel period. So, many packages in Fedora 8 would have .1 instead of a .fc8 as the dist tag, and although they are for Fedora 8 actually, it cannot be seen in the file name. Either the users expect Fedora 8 packages to have .fc8 in the name, or they are confused by packages, which don't have .fc8 in the name, or they don't care. * = Is this crusade against a inherited packages based on experience with a significant number of confused users (e.g. based on reports in message boards)? From bugs.michael at gmx.net Thu Apr 19 15:52:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 Apr 2007 17:52:30 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070419150514.GB29404@ryvius.pekin.waw.pl> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <20070419150514.GB29404@ryvius.pekin.waw.pl> Message-ID: <20070419175230.60ab09af.bugs.michael@gmx.net> On Thu, 19 Apr 2007 17:05:14 +0200, Dominik 'Rathann' Mierzejewski wrote: > Is gg2-devel "highly questionable packaging" as well? No, it isn't. Unlike a couple of other packages we've had before. I've said more than once (and everytime somebody has asked about the multi-lib stuff) that as a last resort individual packages can be put onto the multilib blacklist. I just don't want to be the target of flames and bad mood. There are much nicer ways of how to request something. And we have a committee called FESCo who are in charge of the Fedora multi-lib strategy. From aph at redhat.com Thu Apr 19 16:17:19 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Apr 2007 17:17:19 +0100 Subject: Java packages that should be rebuilt Message-ID: <17959.38415.415115.784530@zebedee.pink> The following Java packages are only partially built. Package maintainers, please press the "rebuild" button. :-) Fedora/axis-1.2.1-2jpp.6.x86_64.rpm: /usr/lib64/gcj/axis/axis-1.2.1.jar.db FAIL (contains 265 of 744 classes) Fedora/bcel-5.1-8jpp.1.x86_64.rpm: /usr/lib64/gcj/bcel/bcel-5.1.jar.db FAIL (contains 364 of 370 classes) Fedora/xalan-j2-2.7.0-6jpp.1.x86_64.rpm: /usr/lib64/gcj/xalan-j2/xalan-j2-2.7.0.jar.db FAIL (contains 129 of 731 classes) Fedora/xerces-j2-2.7.1-7jpp.2.x86_64.rpm: /usr/lib64/gcj/xerces-j2/xerces-j2-2.7.1.jar.db FAIL (contains 448 of 865 classes) Thanks, Andrew. From dominik at greysector.net Thu Apr 19 16:38:39 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 19 Apr 2007 18:38:39 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070419175230.60ab09af.bugs.michael@gmx.net> References: <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <20070419150514.GB29404@ryvius.pekin.waw.pl> <20070419175230.60ab09af.bugs.michael@gmx.net> Message-ID: <20070419163839.GB30819@ryvius.pekin.waw.pl> On Thursday, 19 April 2007 at 17:52, Michael Schwendt wrote: > On Thu, 19 Apr 2007 17:05:14 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > Is gg2-devel "highly questionable packaging" as well? > > No, it isn't. Unlike a couple of other packages we've had before. > > I've said more than once (and everytime somebody has asked about the > multi-lib stuff) that as a last resort individual packages can be put onto > the multilib blacklist. > > I just don't want to be the target of flames and bad mood. There are much > nicer ways of how to request something. Fine. My apologies. I just don't know what to do now. repoclosure is telling me my package is broken and I see no way of fixing it, short of removing some functionality. > And we have a committee called > FESCo who are in charge of the Fedora multi-lib strategy. Would the FESCo please add gg2-(libs|devel) to the multilib exception list, then? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From aph at redhat.com Thu Apr 19 16:58:50 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Apr 2007 17:58:50 +0100 Subject: Java packages that should be rebuilt In-Reply-To: <17959.38415.415115.784530@zebedee.pink> References: <17959.38415.415115.784530@zebedee.pink> Message-ID: <17959.40906.233608.710307@zebedee.pink> Andrew Haley writes: > The following Java packages are only partially built. > > Package maintainers, please press the "rebuild" button. :-) > > Fedora/axis-1.2.1-2jpp.6.x86_64.rpm: > /usr/lib64/gcj/axis/axis-1.2.1.jar.db FAIL (contains 265 of 744 classes) > > Fedora/bcel-5.1-8jpp.1.x86_64.rpm: > /usr/lib64/gcj/bcel/bcel-5.1.jar.db FAIL (contains 364 of 370 classes) > > Fedora/xalan-j2-2.7.0-6jpp.1.x86_64.rpm: > /usr/lib64/gcj/xalan-j2/xalan-j2-2.7.0.jar.db FAIL (contains 129 of 731 classes) > > Fedora/xerces-j2-2.7.1-7jpp.2.x86_64.rpm: > /usr/lib64/gcj/xerces-j2/xerces-j2-2.7.1.jar.db FAIL (contains 448 of 865 classes) > Andrew. Brew(tm) says owner for axis is pcheung. Brew(tm) says owner for bcel is pcheung. Brew(tm) says owner for xalan is gbenson. Brew(tm) says owner for xerces is gbenson. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From pcheung at redhat.com Thu Apr 19 19:15:36 2007 From: pcheung at redhat.com (Permaine Cheung) Date: Thu, 19 Apr 2007 15:15:36 -0400 Subject: Java packages that should be rebuilt In-Reply-To: <17959.40906.233608.710307@zebedee.pink> References: <17959.38415.415115.784530@zebedee.pink> <17959.40906.233608.710307@zebedee.pink> Message-ID: <4627BFD8.1000906@redhat.com> Andrew Haley wrote: > Andrew Haley writes: > > The following Java packages are only partially built. > > > > Package maintainers, please press the "rebuild" button. :-) > > > > Fedora/axis-1.2.1-2jpp.6.x86_64.rpm: > > /usr/lib64/gcj/axis/axis-1.2.1.jar.db FAIL (contains 265 of 744 classes) > > > > Fedora/bcel-5.1-8jpp.1.x86_64.rpm: > > /usr/lib64/gcj/bcel/bcel-5.1.jar.db FAIL (contains 364 of 370 classes) > > > > Fedora/xalan-j2-2.7.0-6jpp.1.x86_64.rpm: > > /usr/lib64/gcj/xalan-j2/xalan-j2-2.7.0.jar.db FAIL (contains 129 of 731 classes) > > > > Fedora/xerces-j2-2.7.1-7jpp.2.x86_64.rpm: > > /usr/lib64/gcj/xerces-j2/xerces-j2-2.7.1.jar.db FAIL (contains 448 of 865 classes) > > Andrew. > > Brew(tm) says owner for axis is pcheung. > Brew(tm) says owner for bcel is pcheung. > > axis and bcel have been rebuilt. Permaine > Brew(tm) says owner for xalan is gbenson. > Brew(tm) says owner for xerces is gbenson. > > Andrew. > > From musuruan at gmail.com Thu Apr 19 19:21:26 2007 From: musuruan at gmail.com (Andrea Musuruane) Date: Thu, 19 Apr 2007 21:21:26 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2007-04-19 In-Reply-To: <1176975772.28550.15.camel@redhat.usu> References: <20070419071006.14739.24035@extras64.linux.duke.edu> <1176975772.28550.15.camel@redhat.usu> Message-ID: <1177010486.4792.5.camel@localhost.localdomain> Il giorno gio, 19/04/2007 alle 11.42 +0200, Jindrich Novy ha scritto: > these packages need to be rebuilt because of the recent update of mikmod > (increased libmikmod soname): > > uqm > xmms > stratagus > tecnoballz > gweled > ClanLib > fbg > methane > > I rebuilt all of those successfully without any modification against the > new libmikmod.so.3 locally. Only ClanLib06 may need some tune-ups. I tried to rebuild tecnoballz. It went fine on i386 but failed on x86_64. Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/31978-tecnoballz-0.91-5.fc7/ It fails in the configure script: [...] checking for Player_Stop in -lmikmod... no configure: error: Could not find the Mikmod library : -lmikmod Are you sure the new mikmod is stable and backwards compatible? Why did you use a beta version? Andrea. From j.w.r.degoede at hhs.nl Thu Apr 19 20:36:10 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 19 Apr 2007 22:36:10 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070419172537.d9cd60a9.bugs.michael@gmx.net> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> <20070419172537.d9cd60a9.bugs.michael@gmx.net> Message-ID: <4627D2BA.3090303@hhs.nl> Michael Schwendt wrote: > On Thu, 19 Apr 2007 16:40:48 +0200, Hans de Goede wrote: > >> Michael Schwendt wrote: >>> No. The pushscript makes available the i386 development packages for >>> x86_64, so you can develop for i386 on x86_64. >>> >> And does this in a very stupid way, for some reason in your reply you didn't >> bother to react to this: > > What is stupid? > That having a -devel subpackage isn't a very smart way to decide wether or not a package should get its i386 version dragged into the x86_64 tree, not smart == stupid. Why not add some additional heuristics using stuff that actually is in the package. The advantages are huge, less i386 packages in the x86_64 tree makes for less mirrorbandwidth wasted, smaller repodata and thus faster user experience, etc. >> --- >> >> No this sounds like a BAD solution to me. We are going to have this problem for >> every non noarch perl / python / ruby / xxx package that happens to split of a >> -devel package (for example because of .pc files). >> >> --- >> >> Where I was talking about the pygame-devel issue, > > pygame-devel is gone as it was broken. It required the main package > without reason, and the main package required 32-bit Python which is not > available for x86_64. The alternative would have been to blacklist > pygame-devel. > How was it broken? Now we have header files installed under /usr/include in a main package, and that is somehow less broken? >> simply putting all .i386 >> packages which have a -devel subpackage / provides in the x86_64 tree is wrong. >> > > Stupid. Wrong. Why? White-list, black-list, what do you refuse to > understand? > Again repeating myself, as you still have not addressed this: "We are going to have this problem for every non noarch perl / python / ruby / xxx package that happens to split of a -devel package (for example because of .pc files)." This is what one calls broken by design. Yet another example, pygtkglext, which is a python wrapper for pygtkglext has a -devel package for the .pc files (as it must according to the guidelines). Thus now we have pygtkglext.i386 in the x86_64 tree, which is not what we want AFAIK. You want me to clarify how the push script could become smarter? : 1) Blacklist by default Py* PY* py* perl* php* and probably others 2) If when resolving deps not all deps can be resolved because this requires i386 packages from core which core hasn't put in the x86_64 tree, then don't include the package with the unresolved deps in the x86_64 tree This will fix the pygtkglext example and would also have meant that there would have been no problems surrounding pygame. > IMO, the gnumeric-devel package is broken and should be eliminated. > It would not be the first -devel package which should never have been > published. gnumeric (and pygame, pygtkglext) are all just examples, this is about the fact that the base principle is broken (or oversimplified if you prefer to call it that). Repeating myself yet another time: "I agree that the -devel subpackage of gnumeric is a strange beast and probably not necessary, but thats not the discussion here" IOW I'll give you the point that we might be better of without gnumeric having a -devel, I say might as I haven't looked into this yet. Regards, Hans From caillon at redhat.com Thu Apr 19 20:45:58 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 19 Apr 2007 16:45:58 -0400 Subject: Fedora 7 Test 4 freeze Tuesday the 17th In-Reply-To: <200704131534.15954.jkeating@redhat.com> References: <200704131534.15954.jkeating@redhat.com> Message-ID: <4627D506.9010503@redhat.com> Jesse Keating wrote: > This will also mark the point in which I'd like to enter a continual slushy > state. Only bugfixes going in, with low risk to breaking other things. > > See http://fedoraproject.org/wiki/Releases/DevelFreezePolicy for policy on > getting things tagged for the freeze tag for now until the end of the F7 > cycle. magic 8 ball says http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy From bugs.michael at gmx.net Thu Apr 19 22:14:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 Apr 2007 00:14:22 +0200 Subject: broken deps outside of packagers control In-Reply-To: <4627D2BA.3090303@hhs.nl> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> <20070419172537.d9cd60a9.bugs.michael@gmx.net> <4627D2BA.3090303@hhs.nl> Message-ID: <20070420001422.cec0a0c6.bugs.michael@gmx.net> On Thu, 19 Apr 2007 22:36:10 +0200, Hans de Goede wrote: > >> And does this in a very stupid way, for some reason in your reply you didn't > >> bother to react to this: > > > > What is stupid? > > > > That having a -devel subpackage isn't a very smart way to decide wether or not > a package should get its i386 version dragged into the x86_64 tree, not smart > == stupid. What a great definition! > Why not add some additional heuristics using stuff that actually is > in the package. You are free to contribute something like that. Any -devel package, which would be excluded, could still be in the dependency-chain of another -devel package, which would be included. The more gets excluded, the easier the dep-chains can break. In other words, excluding potential multi-lib development packages is bad. More about this further below, since you mentioned dep-checking... > The advantages are huge, less i386 packages in the x86_64 tree > makes for less mirrorbandwidth wasted, smaller repodata and thus faster user > experience, etc. It's not implemented yet, the results are unknown, don't guess whether the advantages would be huge. Actually, we have lots of valid i386 -devel packages in the tree. But I'm not convinced that the current multi-lib strategy is good. A separate i386 repo is available, and the i386 pkgs in the x86_64 cause several problems which are documented by many users (e.g. yum installing both i386 and x86_64 and things like that). > >> No this sounds like a BAD solution to me. We are going to have this problem for > >> every non noarch perl / python / ruby / xxx package that happens to split of a > >> -devel package (for example because of .pc files). > >> > >> --- > >> > >> Where I was talking about the pygame-devel issue, > > > > pygame-devel is gone as it was broken. It required the main package > > without reason, and the main package required 32-bit Python which is not > > available for x86_64. The alternative would have been to blacklist > > pygame-devel. > > > > How was it broken? I've rexamined pygame in devel and need to correct myself. 3 of the 4 headers can be used to call pygame via the Python C API. The macros even import Python modules. Well, I'm not the pygame packager. > Again repeating myself, as you still have not addressed this: > > "We are going to have this problem for every non noarch perl / python / ruby / > xxx package that happens to split of a -devel package (for example because of > .pc files)." Nothing I will address, because the Fedora multi-lib strategy is close to undefined. Whether tools would create/update/maintain the white- and black-lists or whether packages would be selected manually, is not anything that is worked on officially and visibly. > This is what one calls broken by design. Yet another example, pygtkglext, which > is a python wrapper for pygtkglext has a -devel package for the .pc files (as > it must according to the guidelines). Thus now we have pygtkglext.i386 in the > x86_64 tree, which is not what we want AFAIK. You want me to clarify how the > push script could become smarter? : No, since the new updates system is under development. > 1) Blacklist by default Py* PY* py* perl* php* and probably others Would be possible. Just needs somebody to come up with a list. > 2) If when resolving deps not all deps can be resolved because this requires > i386 packages from core which core hasn't put in the x86_64 tree, then don't > include the package with the unresolved deps in the x86_64 tree Core and Extras will be merged. Step 2) is not solved for Core yet either, see e.g. broken updates for FC6: https://bugzilla.redhat.com/230194 Doing it in an automated way would need a lot of work (and most likely would benefit from the package db), because it would also need to be possible for entire i386 dep-chains to be withdrawn from the x86_64 repo when an update breaks the chain. > that). Repeating myself yet another time: "I agree that the -devel subpackage > of gnumeric is a strange beast and probably not necessary, but thats not the > discussion here" IOW I'll give you the point that we might be better of without > gnumeric having a -devel, I say might as I haven't looked into this yet. The issues with the main package are more important anyway. ;) From chris.stone at gmail.com Thu Apr 19 22:23:17 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 19 Apr 2007 15:23:17 -0700 Subject: broken deps outside of packagers control In-Reply-To: <20070420001422.cec0a0c6.bugs.michael@gmx.net> References: <46261C7B.4020404@hhs.nl> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> <20070419172537.d9cd60a9.bugs.michael@gmx.net> <4627D2BA.3090303@hhs.nl> <20070420001422.cec0a0c6.bugs.michael@gmx.net> Message-ID: On 4/19/07, Michael Schwendt wrote: > I've rexamined pygame in devel and need to correct myself. 3 of the 4 > headers can be used to call pygame via the Python C API. The macros even > import Python modules. Well, I'm not the pygame packager. NOTE: pygame in devel was packaged the way it is based on *your* recommendations. I appreciate you taking a second look, if something still needs fixing, please let me know. From notting at redhat.com Thu Apr 19 22:22:05 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 19 Apr 2007 18:22:05 -0400 Subject: comps has moved Message-ID: <20070419222205.GB11258@nostromo.devel.redhat.com> The current comps file for Fedora 7 has now moved and is available in the 'comps' module of /cvs/extras as comps-f7.xml.in. The comps file used for extras pushes is now made from this file. Bill From fedora at leemhuis.info Fri Apr 20 05:14:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 20 Apr 2007 07:14:01 +0200 Subject: Wiki updates new comps handling (Re: comps has moved) In-Reply-To: <20070419222205.GB11258@nostromo.devel.redhat.com> References: <20070419222205.GB11258@nostromo.devel.redhat.com> Message-ID: <46284C19.2050401@leemhuis.info> On 20.04.2007 00:22, Bill Nottingham wrote: > The current comps file for Fedora 7 has now moved and is available > in the 'comps' module of /cvs/extras as comps-f7.xml.in. The comps > file used for extras pushes is now made from this file. I updated the wiki docs at http://fedoraproject.org/wiki/PackageMaintainers/CompsXml Just mention it here in case there are other occurrences in the wiki that I'm not aware of that need to be adjusted, too. CU thl P.S.: @notting: this afaics would have been you job ;-) From j.w.r.degoede at hhs.nl Fri Apr 20 07:13:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 20 Apr 2007 09:13:27 +0200 Subject: broken deps outside of packagers control In-Reply-To: <20070420001422.cec0a0c6.bugs.michael@gmx.net> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> <20070419172537.d9cd60a9.bugs.michael@gmx.net> <4627D2BA.3090303@hhs.nl> <20070420001422.cec0a0c6.bugs.michael@gmx.net> Message-ID: <46286817.3030308@hhs.nl> Michael Schwendt wrote: > On Thu, 19 Apr 2007 22:36:10 +0200, Hans de Goede wrote: > >> Why not add some additional heuristics using stuff that actually is >> in the package. > > You are free to contribute something like that. Any -devel package, which > would be excluded, could still be in the dependency-chain of another > -devel package, which would be included. The more gets excluded, the > easier the dep-chains can break. In other words, excluding potential > multi-lib development packages is bad. More about this further below, > since you mentioned dep-checking... > See reply below. >> Again repeating myself, as you still have not addressed this: >> >> "We are going to have this problem for every non noarch perl / python / ruby / >> xxx package that happens to split of a -devel package (for example because of >> .pc files)." > > Nothing I will address, because the Fedora multi-lib strategy is close to > undefined. Whether tools would create/update/maintain the white- and > black-lists or whether packages would be selected manually, is not > anything that is worked on officially and visibly. > So you do agree with me this is a problem? Remember this whole discussion started because of you saying that the fix for broken deps, caused by the current not smart multilib strategy, was to just remove the -devel sub packages or kludge around otherwise. Now if you agree (in the light of examples like pygtkglext and pygame) that just removing -devel packages or doing further split ups is not the way to go, then we can start talking about a real solution. >> This is what one calls broken by design. Yet another example, pygtkglext, which >> is a python wrapper for pygtkglext has a -devel package for the .pc files (as >> it must according to the guidelines). Thus now we have pygtkglext.i386 in the >> x86_64 tree, which is not what we want AFAIK. You want me to clarify how the >> push script could become smarter? : > > No, since the new updates system is under development. > >> 1) Blacklist by default Py* PY* py* perl* php* and probably others > > Would be possible. Just needs somebody to come up with a list. > Well, I've given a start, all we really need todo is take a look at which programming languages we ship, how bindings for those languages are named, and then per language decide whether or not to include both versions of -devel packages of them in multilib archs. Regards, Hans From gbenson at redhat.com Fri Apr 20 07:22:52 2007 From: gbenson at redhat.com (Gary Benson) Date: Fri, 20 Apr 2007 08:22:52 +0100 Subject: Java packages that should be rebuilt In-Reply-To: <17959.40906.233608.710307@zebedee.pink> References: <17959.38415.415115.784530@zebedee.pink> <17959.40906.233608.710307@zebedee.pink> Message-ID: <20070420072252.GA3587@redhat.com> Andrew Haley wrote: > Andrew Haley writes: > > The following Java packages are only partially built. > > > > Package maintainers, please press the "rebuild" button. :-) > > > > Fedora/axis-1.2.1-2jpp.6.x86_64.rpm: > > /usr/lib64/gcj/axis/axis-1.2.1.jar.db FAIL (contains 265 of 744 classes) > > > > Fedora/bcel-5.1-8jpp.1.x86_64.rpm: > > /usr/lib64/gcj/bcel/bcel-5.1.jar.db FAIL (contains 364 of 370 classes) > > > > Fedora/xalan-j2-2.7.0-6jpp.1.x86_64.rpm: > > /usr/lib64/gcj/xalan-j2/xalan-j2-2.7.0.jar.db FAIL (contains 129 of 731 classes) > > > > Fedora/xerces-j2-2.7.1-7jpp.2.x86_64.rpm: > > /usr/lib64/gcj/xerces-j2/xerces-j2-2.7.1.jar.db FAIL (contains 448 of 865 classes) > > Brew(tm) says owner for axis is pcheung. > Brew(tm) says owner for bcel is pcheung. > > Brew(tm) says owner for xalan is gbenson. > Brew(tm) says owner for xerces is gbenson. Brew(tm) says owner for xalan-j2 is vivekl. Brew(tm) says owner for xerces-j2 is mwringe. Cheers, Gary From bugs.michael at gmx.net Fri Apr 20 08:57:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 Apr 2007 10:57:30 +0200 Subject: broken deps outside of packagers control In-Reply-To: <46286817.3030308@hhs.nl> References: <46261C7B.4020404@hhs.nl> <46261E05.1090708@leemhuis.info> <20070418135938.GA18203@redhat.com> <20070418163431.5a502c29.bugs.michael@gmx.net> <46265C68.7050902@hhs.nl> <1176921455.28087.7.camel@tuxhugs> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> <20070419172537.d9cd60a9.bugs.michael@gmx.net> <4627D2BA.3090303@hhs.nl> <20070420001422.cec0a0c6.bugs.michael@gmx.net> <46286817.3030308@hhs.nl> Message-ID: <20070420105730.5bb478ad.bugs.michael@gmx.net> On Fri, 20 Apr 2007 09:13:27 +0200, Hans de Goede wrote: > > Nothing I will address, because the Fedora multi-lib strategy is close to > > undefined. Whether tools would create/update/maintain the white- and > > black-lists or whether packages would be selected manually, is not > > anything that is worked on officially and visibly. > > > > So you do agree with me this is a problem? Remember this whole discussion > started because of you saying that the fix for broken deps, caused by the > current not smart multilib strategy, was to just remove the -devel sub packages > or kludge around otherwise. No, you twist words here and mix things up. It is not my general advise to eliminate -devel packages as the one and only way to get a package excluded from the multi-lib resolver. I always point out that packages can be put onto the blacklist. It is not documented anywhere, however, as what packages we do want as multi-lib. For many application packages, which have a -devel sub-package, it *is* possible to split off the libraries (as Peter Gordon has pointed out in this thread), so the -devel package no longer requires the main application package, but only the -libs package. That results in an increased number of packages, and is argueable, but for some types of packages it does work. And again, whether we want that for all small applications is questionable and not covered by any guideline. On pygame: When I skimmed over the contents of pygame-devel in Dec 2006, the first file was a pure C header without any Python stuff in it and without any corresponding library to link to. That put me on a false track. I should have looked less briefly, since macros in the other three headers do import Python modules via the Python C API. Christopher was free to point out my mistake instead of eliminating "Requires: Python-devel SDL-devel SDL_mixer-devel" without any replacement. He could also have consulted the original reviewer of the package and request a second opinion. On gnumeric: The package name alone is not enough to decide whether to make it multi-lib. Also your proposed wildcards would *not* have excluded it by default. Perl.i386 was available for x86_64 for a long time (see e.g. FC6), and simply nobody has noticed so far that gnumeric-devel and gnumeric are broken, at least a bit: https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00401.html You can prove me wrong. Maybe where my brief look found a missing executable, an unexpanded variable and a superfluous symlink, there is a way to fix all that without ending with an empty gnumeric-devel package. But without looking into it, please don't suggest that a separate gnumeric-devel package for a single *.idl file is justified. Finally, if there is no way to avoid the gnumeric-devel package (e.g. after fixing the package contents), it *is* possible to blacklist it for multilib -- and it is on the blacklist already as Fedora 7 is getting closer. From bugs.michael at gmx.net Fri Apr 20 09:00:02 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 20 Apr 2007 11:00:02 +0200 Subject: Wiki updates new comps handling (Re: comps has moved) In-Reply-To: <46284C19.2050401@leemhuis.info> References: <20070419222205.GB11258@nostromo.devel.redhat.com> <46284C19.2050401@leemhuis.info> Message-ID: <20070420110002.94c4aba1.bugs.michael@gmx.net> On Fri, 20 Apr 2007 07:14:01 +0200, Thorsten Leemhuis wrote: > On 20.04.2007 00:22, Bill Nottingham wrote: > > The current comps file for Fedora 7 has now moved and is available > > in the 'comps' module of /cvs/extras as comps-f7.xml.in. The comps > > file used for extras pushes is now made from this file. The comps-fe7.xml.in target that creates the symlink didn't work for me, since it is not a default target (see the wildcards at the top of the Makefile. As a work-around, I've simply reconfigured the pushscript config file to use comps-f7.xml instead, and that worked fine. From aph at redhat.com Fri Apr 20 09:27:50 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Apr 2007 10:27:50 +0100 Subject: Java packages that should be rebuilt In-Reply-To: <20070420072252.GA3587@redhat.com> References: <17959.38415.415115.784530@zebedee.pink> <17959.40906.233608.710307@zebedee.pink> <20070420072252.GA3587@redhat.com> Message-ID: <17960.34710.98630.134027@zebedee.pink> Gary Benson writes: > Andrew Haley wrote: > > Andrew Haley writes: > > > The following Java packages are only partially built. > > > > > > Package maintainers, please press the "rebuild" button. :-) > > > > > > Fedora/axis-1.2.1-2jpp.6.x86_64.rpm: > > > /usr/lib64/gcj/axis/axis-1.2.1.jar.db FAIL (contains 265 of 744 classes) > > > > > > Fedora/bcel-5.1-8jpp.1.x86_64.rpm: > > > /usr/lib64/gcj/bcel/bcel-5.1.jar.db FAIL (contains 364 of 370 classes) > > > > > > Fedora/xalan-j2-2.7.0-6jpp.1.x86_64.rpm: > > > /usr/lib64/gcj/xalan-j2/xalan-j2-2.7.0.jar.db FAIL (contains 129 of 731 classes) > > > > > > Fedora/xerces-j2-2.7.1-7jpp.2.x86_64.rpm: > > > /usr/lib64/gcj/xerces-j2/xerces-j2-2.7.1.jar.db FAIL (contains 448 of 865 classes) > > > > Brew(tm) says owner for axis is pcheung. > > Brew(tm) says owner for bcel is pcheung. > > > > Brew(tm) says owner for xalan is gbenson. > > Brew(tm) says owner for xerces is gbenson. > > Brew(tm) says owner for xalan-j2 is vivekl. > Brew(tm) says owner for xerces-j2 is mwringe. Oh yeah. Forwarding... Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From limb at jcomserv.net Fri Apr 20 11:28:01 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 20 Apr 2007 06:28:01 -0500 (CDT) Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover Message-ID: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 It has been 3 weeks with no contact. Axel Thimm (Axel.Thimm at ATrpms.net) has requested to be made the maintainer of both nx and freenx, pending a 3 day wait and approval by a FESCO member. He already has much of the needed work on these packages prepared. Jon Ciesla -- novus ordo absurdum From buildsys at fedoraproject.org Fri Apr 20 13:21:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 20 Apr 2007 09:21:18 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-20 Message-ID: <20070420132118.335B7152131@buildsys.fedoraproject.org> enrico.scholz AT informatik.tu-chemnitz.de: util-vserver FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) gauret AT free.fr: php-adodb FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) php-adodb: gauret AT free.fr FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) util-vserver: enrico.scholz AT informatik.tu-chemnitz.de FE5 > FE7 (0:0.30.212-1.fc5 > 0:0.30.211-1.fc6) FE6 > FE7 (0:0.30.212-3.fc6 > 0:0.30.211-1.fc6) From kwade at redhat.com Fri Apr 20 17:08:43 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 20 Apr 2007 10:08:43 -0700 Subject: Release notes freezing for F7 Message-ID: <1177088923.3286.415.camel@erato.phig.org> Today is your last chance[1] to get content into the ISO-based release notes for Fedora 7: http://fedoraproject.org/wiki/Docs/Beats It is highly likely that you actually have 24 more hours until we actually start commuting changes from the Wiki into XML. So, hurry! If you miss this opportunity, don't freak out. Any changes made to Docs/Beats after this date are made available as part of a Web-only, latest release notes that we post when Fedora 7 ships. - Karsten [1] http://fedoraproject.org/wiki/DocsProject/Schedule -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 musuruan at gmail.com Fri Apr 20 19:52:37 2007 From: musuruan at gmail.com (Andrea Musuruane) Date: Fri, 20 Apr 2007 21:52:37 +0200 Subject: Summary - Broken dependencies in Fedora Extras - 2007-04-19 In-Reply-To: <1177010486.4792.5.camel@localhost.localdomain> References: <20070419071006.14739.24035@extras64.linux.duke.edu> <1176975772.28550.15.camel@redhat.usu> <1177010486.4792.5.camel@localhost.localdomain> Message-ID: <1177098757.3380.2.camel@localhost.localdomain> Il giorno gio, 19/04/2007 alle 21.21 +0200, Andrea Musuruane ha scritto: > Il giorno gio, 19/04/2007 alle 11.42 +0200, Jindrich Novy ha scritto: > > these packages need to be rebuilt because of the recent update of mikmod > > (increased libmikmod soname): > > > > uqm > > xmms > > stratagus > > tecnoballz > > gweled > > ClanLib > > fbg > > methane > > > > I rebuilt all of those successfully without any modification against the > > new libmikmod.so.3 locally. Only ClanLib06 may need some tune-ups. > > I tried to rebuild tecnoballz. It went fine on i386 but failed on > x86_64. > > Build logs may be found at > http://buildsys.fedoraproject.org/logs/fedora-development-extras/31978-tecnoballz-0.91-5.fc7/ > > It fails in the configure script: > [...] > checking for Player_Stop in -lmikmod... no > configure: error: Could not find the Mikmod library : -lmikmod > > Are you sure the new mikmod is stable and backwards compatible? Why did > you use a beta version? And why did you upgraded mikmod to a major version during a feature freeze? Andrea. From pertusus at free.fr Fri Apr 20 21:47:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 23:47:25 +0200 Subject: ssh key of cvs server changed? Message-ID: <20070420214725.GL3045@free.fr> Hello, It may also be a issue in my setup, but it seems that the ssh key of the cvs server changed: The authenticity of host 'cvs.fedora.redhat.com (209.132.176.51)' can't be established. RSA key fingerprint is dd:0d:f1:d6:e2:f6:39:cf:ca:6b:03:28:8d:84:3a:d5. Is it normal? I have in my known_hosts file cvs.fedora.redhat.com,209.132.176.51 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAulP7NbbRFCjHe9DR5UZ4BG89V59/dm55d+1+M8FGfFMhrJHhBRfHNi6CRz3WVeO3yE+x030PzOHhvdA8x9LhBKOEHs+2BqgYTAki1RMzjlk2fEihBzUrJT40A0KvjBLVoWxNMc/SL5rUB7smhrmnO3QH/EWaKxNiBvlNa5ZW4Js= -- Pat From pertusus at free.fr Fri Apr 20 21:51:35 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 23:51:35 +0200 Subject: ssh key of cvs server changed? In-Reply-To: <20070420214725.GL3045@free.fr> References: <20070420214725.GL3045@free.fr> Message-ID: <20070420215135.GA7208@free.fr> On Fri, Apr 20, 2007 at 11:47:25PM +0200, Patrice Dumas wrote: > Hello, > > It may also be a issue in my setup, but it seems that the ssh key of the > cvs server changed: In fact it seems that I need to add my passphrase before server key verification can happen... Sorry. -- Pat From pertusus at free.fr Fri Apr 20 21:53:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 20 Apr 2007 23:53:43 +0200 Subject: ssh key of cvs server changed? In-Reply-To: <20070420214725.GL3045@free.fr> References: <20070420214725.GL3045@free.fr> Message-ID: <20070420215343.GB7208@free.fr> On Fri, Apr 20, 2007 at 11:47:25PM +0200, Patrice Dumas wrote: > RSA key fingerprint is dd:0d:f1:d6:e2:f6:39:cf:ca:6b:03:28:8d:84:3a:d5. > > I have in my known_hosts file > cvs.fedora.redhat.com,209.132.176.51 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAulP7NbbRFCjHe9DR5UZ4BG89V59/dm55d+1+M8FGfFMhrJHhBRfHNi6CRz3WVeO3yE+x030PzOHhvdA8x9LhBKOEHs+2BqgYTAki1RMzjlk2fEihBzUrJT40A0KvjBLVoWxNMc/SL5rUB7smhrmnO3QH/EWaKxNiBvlNa5ZW4Js= And dd:0d:f1:d6:e2:f6:39:cf:ca:6b:03:28:8d:84:3a:d5 is the fingerprint of the ssh-rsa key.... -- Pat From chris.stone at gmail.com Fri Apr 20 22:54:58 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Fri, 20 Apr 2007 15:54:58 -0700 Subject: broken deps outside of packagers control In-Reply-To: <20070420105730.5bb478ad.bugs.michael@gmx.net> References: <46261C7B.4020404@hhs.nl> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> <20070419172537.d9cd60a9.bugs.michael@gmx.net> <4627D2BA.3090303@hhs.nl> <20070420001422.cec0a0c6.bugs.michael@gmx.net> <46286817.3030308@hhs.nl> <20070420105730.5bb478ad.bugs.michael@gmx.net> Message-ID: On 4/20/07, Michael Schwendt wrote: > On pygame: When I skimmed over the contents of pygame-devel in Dec 2006, > the first file was a pure C header without any Python stuff in it and > without any corresponding library to link to. That put me on a false > track. I should have looked less briefly, since macros in the other three > headers do import Python modules via the Python C API. Christopher was > free to point out my mistake instead of eliminating "Requires: Python-devel > SDL-devel SDL_mixer-devel" without any replacement. He could also have > consulted the original reviewer of the package and request a second > opinion. Obviously this multi-lib issue was well beyond my capability of understanding. I assumed you knew what you were talking about with pygame. So now you are saying I should add the pygame-devel package back and let it be blacklisted? Do not assume I understand how pygame works just because I package it. I package pygame because it is a necessary evil for another package that I _do_ care about. If someone who has an intimate knowledge of pygame wants to take over maintainership of it, please let me know. Otherwise I will struggle through being its maintainer. From buildsys at fedoraproject.org Sat Apr 21 14:20:11 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 21 Apr 2007 10:20:11 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-21 Message-ID: <20070421142011.96663152131@buildsys.fedoraproject.org> gauret AT free.fr: php-adodb FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) php-adodb: gauret AT free.fr FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) From wtogami at redhat.com Sat Apr 21 19:46:43 2007 From: wtogami at redhat.com (Warren Togami) Date: Sat, 21 Apr 2007 15:46:43 -0400 Subject: Spilt libperl from perl Message-ID: <462A6A23.5030409@redhat.com> During the last FESCO meeting there was (reluctant?) agreement that splitting libperl.so from perl would be a better solution to workaround our broken multilib policy than to split perl sub-packages out of everything that breaks due to perl.i386 being removed from F7 x86-64. Is this going to happen? Warren Togami wtogami at redhat.com From chris.stone at gmail.com Sat Apr 21 20:14:11 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 21 Apr 2007 13:14:11 -0700 Subject: broken deps outside of packagers control In-Reply-To: References: <46261C7B.4020404@hhs.nl> <4627007E.2090007@hhs.nl> <20070419102257.04004858.bugs.michael@gmx.net> <46277F70.4010305@hhs.nl> <20070419172537.d9cd60a9.bugs.michael@gmx.net> <4627D2BA.3090303@hhs.nl> <20070420001422.cec0a0c6.bugs.michael@gmx.net> <46286817.3030308@hhs.nl> <20070420105730.5bb478ad.bugs.michael@gmx.net> Message-ID: Hans: you might be interested in this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235758 From peter at thecodergeek.com Sat Apr 21 23:23:37 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 21 Apr 2007 16:23:37 -0700 Subject: Mock & yum.conf Don't Play Nicely... Message-ID: <1177197817.10880.11.camel@tuxhugs> Hi, all. I'm going through the vegastrike reviews and I can't seem to build anything in mock. Whether or not I use the autocache feature, it still bails out with the following error: $ mock --debug --autocache -r fedora-devel-x86_64-core SRPMS/vegastrike* DEBUG: ensuring dir /var/lib/mock/fedora-development-x86_64-core/root/etc/yum Traceback (most recent call last): File "/usr/bin/mock", line 1046, in main() File "/usr/bin/mock", line 1043, in main do_rebuild(config_opts, srpms) File "/usr/bin/mock", line 910, in do_rebuild my.prep() File "/usr/bin/mock", line 254, in prep self._prep_install() File "/usr/bin/mock", line 659, in _prep_install os.symlink('../yum.conf', os.path.join(yumdir, 'yum.conf')) OSError: [Errno 17] File exists I did a bit of googling, and it seems this was seen by Chitlesh GOORAH about a month ago; but no workaround/fix was addressed in that thread which he started. Nor could I find it in the list of bugs for the mock component on Fedora's bugzilla either. My mock configs are the default; and I'm using x86_64 Development updated as of this morning (20070421 rawhide). Is there a patch I can apply or something I can tweak in the mock config to make it stop doing this? Thanks for any help/advice. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 mtasaka at ioa.s.u-tokyo.ac.jp Sun Apr 22 00:01:36 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 22 Apr 2007 09:01:36 +0900 Subject: Mock & yum.conf Don't Play Nicely... In-Reply-To: <1177197817.10880.11.camel@tuxhugs> References: <1177197817.10880.11.camel@tuxhugs> Message-ID: <462AA5E0.90705@ioa.s.u-tokyo.ac.jp> Peter Gordon wrote, at 04/22/2007 08:23 AM +9:00: > Hi, all. I'm going through the vegastrike reviews and I can't seem to > build anything in mock. Whether or not I use the autocache feature, it > still bails out with the following error: > > $ mock --debug --autocache -r fedora-devel-x86_64-core SRPMS/vegastrike* > DEBUG: ensuring > dir /var/lib/mock/fedora-development-x86_64-core/root/etc/yum > Traceback (most recent call last): > File "/usr/bin/mock", line 1046, in > main() > File "/usr/bin/mock", line 1043, in main > do_rebuild(config_opts, srpms) > File "/usr/bin/mock", line 910, in do_rebuild > my.prep() > File "/usr/bin/mock", line 254, in prep > self._prep_install() > File "/usr/bin/mock", line 659, in _prep_install > os.symlink('../yum.conf', os.path.join(yumdir, 'yum.conf')) > OSError: [Errno 17] File exists This message is very similar with the bug I reported: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230824 Current workarround is to downgrade mock to 0.6.11. Mamoru From buildsys at fedoraproject.org Sun Apr 22 02:02:24 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 21 Apr 2007 22:02:24 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-21 Message-ID: <20070422020224.578A6152131@buildsys.fedoraproject.org> gauret AT free.fr: php-adodb FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) php-adodb: gauret AT free.fr FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) From jasperhartline at adelphia.net Sun Apr 22 01:40:43 2007 From: jasperhartline at adelphia.net (Jasper Hartline) Date: Sat, 21 Apr 2007 20:40:43 -0500 Subject: Kadischi package maintainer cannot be found Message-ID: <462ABD1B.6090104@adelphia.net> Hi. I've made several attempts via IRC, in channel #fedora-livecd on irc.freenode.net IRC server to contact Chitlesh Goorah to continue the process of taking over the Kadischi package in Extras. He did not respond to me on IRC, and is not responding to me via email to the fedora-livecd-list at redhat.com either. What should I do to claim responsibility of this package if the maintainer cannot be reached and is not currently making updates to the package? J. Hartline From tibbs at math.uh.edu Sun Apr 22 02:38:50 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Apr 2007 21:38:50 -0500 Subject: Kadischi package maintainer cannot be found In-Reply-To: <462ABD1B.6090104@adelphia.net> References: <462ABD1B.6090104@adelphia.net> Message-ID: >>>>> "JH" == Jasper Hartline writes: JH> What should I do to claim responsibility of this package if the JH> maintainer cannot be reached and is not currently making updates JH> to the package? http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers - J< From buildsys at fedoraproject.org Sun Apr 22 20:16:39 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 22 Apr 2007 16:16:39 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-22 Message-ID: <20070422201639.5280D152131@buildsys.fedoraproject.org> bdpepple AT ameritech.net: wesnoth FE5 > FE7 (0:1.2.4-1.fc5 > 0:1.2.3-1.fc7) FE6 > FE7 (0:1.2.4-1.fc6 > 0:1.2.3-1.fc7) cgoorah AT yahoo.com.au: dolphin FE5 > FE7 (0:0.8.2-2.fc5 > 0:0.8.2-1.fc7) FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-1.fc7) gauret AT free.fr: php-adodb FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) jamatos AT fc.up.pt: t1lib FE5 > FE7 (0:5.1.0-9.fc5 > 0:5.1.0-8.fc6) FE6 > FE7 (0:5.1.0-9.fc6 > 0:5.1.0-8.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) ryo-dairiki AT users.sourceforge.net: VLGothic-fonts FE5 > FE7 (0:20070328-1.fc5 > 0:20070101-1.fc7) FE6 > FE7 (0:20070328-1.fc6 > 0:20070101-1.fc7) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- dolphin: cgoorah AT yahoo.com.au FE5 > FE7 (0:0.8.2-2.fc5 > 0:0.8.2-1.fc7) FE6 > FE7 (0:0.8.2-2.fc6 > 0:0.8.2-1.fc7) dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) php-adodb: gauret AT free.fr FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) t1lib: jamatos AT fc.up.pt FE5 > FE7 (0:5.1.0-9.fc5 > 0:5.1.0-8.fc6) FE6 > FE7 (0:5.1.0-9.fc6 > 0:5.1.0-8.fc6) VLGothic-fonts: ryo-dairiki AT users.sourceforge.net FE5 > FE7 (0:20070328-1.fc5 > 0:20070101-1.fc7) FE6 > FE7 (0:20070328-1.fc6 > 0:20070101-1.fc7) wesnoth: bdpepple AT ameritech.net FE5 > FE7 (0:1.2.4-1.fc5 > 0:1.2.3-1.fc7) FE6 > FE7 (0:1.2.4-1.fc6 > 0:1.2.3-1.fc7) From peter at thecodergeek.com Sun Apr 22 21:24:58 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 22 Apr 2007 14:24:58 -0700 Subject: [resolved] Re: Mock & yum.conf Don't Play Nicely... In-Reply-To: <462AA5E0.90705@ioa.s.u-tokyo.ac.jp> References: <1177197817.10880.11.camel@tuxhugs> <462AA5E0.90705@ioa.s.u-tokyo.ac.jp> Message-ID: <1177277098.3440.7.camel@tuxhugs> On Sun, 2007-04-22 at 09:01 +0900, Mamoru Tasaka wrote: > This message is very similar with the bug I reported: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230824 > > Current [workaround] is to downgrade mock to 0.6.11. Thanks, Mamoru; I grabbed the 0.6.13 source RPM from the website and that looks to have fixed it. Now I just need to let the buildroot and dependencies download. I'll let that go on its own while I grab some lunch. :) -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 peter at thecodergeek.com Sun Apr 22 21:24:58 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 22 Apr 2007 14:24:58 -0700 Subject: [resolved] Re: Mock & yum.conf Don't Play Nicely... In-Reply-To: <462AA5E0.90705@ioa.s.u-tokyo.ac.jp> References: <1177197817.10880.11.camel@tuxhugs> <462AA5E0.90705@ioa.s.u-tokyo.ac.jp> Message-ID: <1177277098.3440.7.camel@tuxhugs> On Sun, 2007-04-22 at 09:01 +0900, Mamoru Tasaka wrote: > This message is very similar with the bug I reported: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230824 > > Current [workaround] is to downgrade mock to 0.6.11. Thanks, Mamoru; I grabbed the 0.6.13 source RPM from the website and that looks to have fixed it. Now I just need to let the buildroot and dependencies download. I'll let that go on its own while I grab some lunch. :) -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 bpepple at fedoraproject.org Sun Apr 22 20:33:52 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 22 Apr 2007 16:33:52 -0400 Subject: FESCo Meeting Summary for 2007-04-19 Message-ID: <1177274032.14554.4.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (c4chris) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Josh Boyer (jwb) * Jeremy Katz (jeremy) * Bill Nottingham (notting) * Tom Callaway (spot) * Warren Togami (warren) === Absent === * Dennis Gilmore (dgilmore) * Jesse Keating (f13) * Rex Dieter (rdieter) == Summary == === Packaging Committee Report === * FESCo approved the Packaging Committee's guidelines regarding: * Minor clarifications to the filename encoding guidelines === Vote on rebuilding packages with old disttag === * FESCo voted against a proposal to rebuild packages with old disttag's. This was decision was based on the fact that there has not been any major changes in the toolchain for Fedora 7, and this would avoid making end users download the packages for only a release tag change. === Comps process === * FESCo approved notting's proposal to move the f7 comps from internal RH CVS to the same place as extras comps, so there's only one file for f7. === Misc === * Discussed upcoming FESCo election. * Discussed i386 libperl in x86_64 broken deps. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070419 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 petersen at redhat.com Mon Apr 23 00:23:38 2007 From: petersen at redhat.com (Jens Petersen) Date: Mon, 23 Apr 2007 10:23:38 +1000 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <462660F6.2070909@redhat.com> References: <462660F6.2070909@redhat.com> Message-ID: <462BFC8A.4090704@redhat.com> Hi Warren, I was away from Wednesday last week so sorry for not being able to follow up quickly. Thank you for bringing this up for wider discussion. :) A few comments: Warren Togami wrote: > Due to the enabled-by-default behavior, SCIM annoys non-SCIM users who > accidentally hit SCIM hotkeys, popping up the language bar or inputting > unwanted characters. Actually we would really appreciate more bug reports against scim detailing all the problems of running it by default so that they could be addressed. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235435 > In an attempt to mitigate this enabled-by-default behavior, this change > was hastily made without being thoroughly thought through. It disables > the SCIM activation hotkey (CTRL-Space) if you login to a new user > profile for the first time with a language that doesn't normally need SCIM. My thinking was that it is easier for infrequent scim-users just to use the mouse to activate and deactivate scim: rather than having to go into im-chooser and restart their desktop. > Disabling the hotkey by default is problematic: > =============================================== > - This creates inconsistent behavior between SCIM user profiles created > at different times, depending on what locale and version of Fedora was > running at the time. True, but I don't see it as such a big problem. > - This forces certain users to use a confusingly disjoint configuration > within SCIM Setup, which is separate from im-chooser. (User confusion) But unfortunately the reverse is also true: turning off scim by default forces users to use im-chooser to turn it on. > - This still has an unnecessary memory footprint for users who > absolutely never need SCIM. Yep. > 1) Undo the hack made in Bug #235435. Ok. I would still like to encourage more discussion on the default hotkey binding. I am not convinced that Ctrl-Space is the best default choice, even though it is the current defacto choice. AFAIK the main reason Ctrl-Space is the current default is because it is commonly used by Chinese IMs. It conflicts with common keybindings in emacs, eclipse and other applications. > 2) Change SCIM's automatic launching to be locale specific. For > example, Asian languages are in a SCIM automatic list, so launch > automatically in those languages. Do not launch SCIM automatically in > other languages. We considered this solution and though I can see it is probably the most pragmatic solution, I was reluctant to go that way since I see it a regression in behaviour. To me having scim run by default when installed provided a much better user experience than having to turn it on manually. But I can see that in the context of the livecd and the new comps this is probably the best we can do at this time. > Can we please implement this before Fedora 7? The SCIM running by > default in all desktop languages is unacceptable, and the hack in Bug > #235435 confuses the issue, hiding the real problem. I can certainly modify the scim side easily this week so there should be enough time to test it for F7. Jens From Axel.Thimm at ATrpms.net Mon Apr 23 11:29:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Apr 2007 13:29:15 +0200 Subject: FESCo Meeting Summary for 2007-04-19 In-Reply-To: <1177274032.14554.4.camel@lincoln> References: <1177274032.14554.4.camel@lincoln> Message-ID: <20070423112915.GI1248@neu.nirvana> On Sun, Apr 22, 2007 at 04:33:52PM -0400, Brian Pepple wrote: > === Vote on rebuilding packages with old disttag === > * FESCo voted against a proposal to rebuild packages with old > disttag's. This was decision was based on the fact that there has not > been any major changes in the toolchain for Fedora 7, and this would > avoid making end users download the packages for only a release tag > change. Was fesco aware that we're talking about a download size of less than 2% [1] and that the disttag confusion is the least of the upcoming potential problems [2]? Was it clear that this is the first time ever Fedora rebuilds less than 95% of its packages (FC did 95-100% rebuilds, FE > 99%, now it's 80% and 62% respectively) [3]? These "details" are rather important. And the rebuilds for the broken packages are doomed to happen, the choice is just whether it's during development in one bulk or during maintenance as each broken package is reported. [1] https://www.redhat.com/archives/fedora-advisory-board/2007-April/msg00169.html [2] https://www.redhat.com/archives/fedora-advisory-board/2007-April/msg00118.html [3] https://www.redhat.com/archives/fedora-advisory-board/2007-April/msg00120.html -- 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 chitlesh at fedoraproject.org Mon Apr 23 11:30:00 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 23 Apr 2007 13:30:00 +0200 Subject: Kadischi package maintainer cannot be found In-Reply-To: <462ABD1B.6090104@adelphia.net> References: <462ABD1B.6090104@adelphia.net> Message-ID: <13dbfe4f0704230430n1da8eac0yb4d6d2bf74efafaa@mail.gmail.com> On 4/22/07, Jasper Hartline wrote: > Hi. > > I've made several attempts via IRC, in channel #fedora-livecd > on irc.freenode.net IRC server to contact Chitlesh Goorah to > continue the process of taking over the Kadischi package in Extras. > > He did not respond to me on IRC, and is not responding to me via email > to the fedora-livecd-list at redhat.com either. What should I do to claim > responsibility of this package if the maintainer cannot be reached > and is not currently making updates to the package? Sorry, I was offline last week. Ownership change was requested: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237402 regards, Chitlesh -- http://clunixchit.blogspot.com From jwboyer at jdub.homelinux.org Mon Apr 23 11:39:40 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 23 Apr 2007 06:39:40 -0500 Subject: FESCo Meeting Summary for 2007-04-19 In-Reply-To: <20070423112915.GI1248@neu.nirvana> References: <1177274032.14554.4.camel@lincoln> <20070423112915.GI1248@neu.nirvana> Message-ID: <1177328380.25513.81.camel@vader.jdub.homelinux.org> On Mon, 2007-04-23 at 13:29 +0200, Axel Thimm wrote: > On Sun, Apr 22, 2007 at 04:33:52PM -0400, Brian Pepple wrote: > > === Vote on rebuilding packages with old disttag === > > * FESCo voted against a proposal to rebuild packages with old > > disttag's. This was decision was based on the fact that there has not > > been any major changes in the toolchain for Fedora 7, and this would > > avoid making end users download the packages for only a release tag > > change. > > Was fesco aware that we're talking about a download size of less than > 2% [1] and that the disttag confusion is the least of the upcoming > potential problems [2]? Was it clear that this is the first time ever > Fedora rebuilds less than 95% of its packages (FC did 95-100% > rebuilds, FE > 99%, now it's 80% and 62% respectively) [3]? These > "details" are rather important. Yes. A mass rebuild was voted down. josh From buildsys at fedoraproject.org Mon Apr 23 13:03:04 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 23 Apr 2007 09:03:04 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-23 Message-ID: <20070423130304.01C72152131@buildsys.fedoraproject.org> gauret AT free.fr: php-adodb FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) php-adodb: gauret AT free.fr FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) From kevin at tummy.com Mon Apr 23 19:05:10 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 23 Apr 2007 13:05:10 -0600 Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover In-Reply-To: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> References: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> Message-ID: <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> On Fri, 20 Apr 2007 06:28:01 -0500 (CDT) limb at jcomserv.net ("Jon Ciesla") wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > > It has been 3 weeks with no contact. > > Axel Thimm (Axel.Thimm at ATrpms.net) has requested to be made the > maintainer of both nx and freenx, pending a 3 day wait and approval > by a FESCO member. I see no problems with this. It does indeed appear that the maintainer is not reachable. ;( Don't forget to reassign those bugs when the ownership change is made. > > He already has much of the needed work on these packages prepared. Excellent. > Jon Ciesla kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Mon Apr 23 19:14:02 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 Apr 2007 15:14:02 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <462BFC8A.4090704@redhat.com> References: <462660F6.2070909@redhat.com> <462BFC8A.4090704@redhat.com> Message-ID: <462D057A.30802@redhat.com> Jens Petersen wrote:> >> 2) Change SCIM's automatic launching to be locale specific. For >> example, Asian languages are in a SCIM automatic list, so launch >> automatically in those languages. Do not launch SCIM automatically in >> other languages. > > We considered this solution and though I can see it is probably the most > pragmatic solution, I was reluctant to go that way since I see it a > regression in behaviour. To me having scim run by default when > installed provided a much better user experience than having to turn it > on manually. But I can see that in the context of the livecd and the > new comps this is probably the best we can do at this time. Enabled by default but with no hotkey is not ideal for the majority of non-Asian users due to the unnecessary memory overhead. How is this bad really? - Asian users get the behavior they expect by default. - Non-Asian users get the behavior they expect by default. - If you are in the extreme minority that needs non-default behavior, it is perfectly reasonable to expect these users to choose a custom setting. It doesn't make sense to inconvenience the majority of users to make it slightly simpler for these rare users. - These rare users already have to enable it with a non-default configuration in other operating systems. This is nothing new, and I would disagree that this is a regression. I strongly believe that this is the right decision. Also consider the impact on RHEL5 users, where the complaint of this bug originated. How do you think the non-Asian users will feel when RHEL-5.1 forces them to install SCIM and it is using memory always, when they don't need it? It is simply the right decision for default software behavior to cater to the majority of users expectations, and require rare users to explicitly change a configuration. > >> Can we please implement this before Fedora 7? The SCIM running by >> default in all desktop languages is unacceptable, and the hack in Bug >> #235435 confuses the issue, hiding the real problem. > > I can certainly modify the scim side easily this week so there should be > enough time to test it for F7. > Sorry, this was considered a Test4 blocker so I have already reverted it a few days ago. You might want to check that it was backed out properly. I did not mean for this to seem like decisions were forced. I think we can still improve this further with further discussion. For example, Desktop team would like eventually more tightly integrate SCIM activation/configuration with GNOME's session and capplets. This would enable activation of SCIM during any running session instead of requiring a desktop relog. There are opportunities to improve our default launch behavior in conjunction with this. Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon Apr 23 19:17:58 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 Apr 2007 15:17:58 -0400 Subject: Spilt libperl from perl In-Reply-To: <462A6A23.5030409@redhat.com> References: <462A6A23.5030409@redhat.com> Message-ID: <462D0666.2000201@redhat.com> Warren Togami wrote: > During the last FESCO meeting there was (reluctant?) agreement that > splitting libperl.so from perl would be a better solution to workaround > our broken multilib policy than to split perl sub-packages out of > everything that breaks due to perl.i386 being removed from F7 x86-64. > > Is this going to happen? > In today's Release Engineering meeting, it was decided that the libperl multilib conflicts are a Test4 blocker. So we need to split libperl.so into a sub-package. The attached patch could theoretically do this, but I haven't been able to make a successful build. This patch is also sub-optimal in that the defined compat version dirs need to be modified manually in yet another part of the spec whenever they change. I thought about using a filelist to allow dynamic generation of this based on %{perlmodcompat}, but there does not seem to be a way to use a filelist in %exclude of the main perl package to make this possible Warren Togami wtogami at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: perl.spec.patch Type: text/x-patch Size: 1776 bytes Desc: not available URL: From jkeating at redhat.com Mon Apr 23 19:14:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Apr 2007 15:14:50 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <462D057A.30802@redhat.com> References: <462660F6.2070909@redhat.com> <462BFC8A.4090704@redhat.com> <462D057A.30802@redhat.com> Message-ID: <200704231514.50995.jkeating@redhat.com> On Monday 23 April 2007 15:14:02 Warren Togami wrote: > Also consider the impact on RHEL5 users, where the complaint of this bug > ? originated. ?How do you think the non-Asian users will feel when > RHEL-5.1 forces them to install SCIM and it is using memory always, when > they don't need it? Warren, changes we make in Fedora 7 have little to no impact on RHEL5(.?) Comps is completely forked, packages are now forked no more inheritance, etc... -- 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 limb at jcomserv.net Mon Apr 23 19:17:08 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 23 Apr 2007 14:17:08 -0500 (CDT) Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover In-Reply-To: <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> References: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> Message-ID: <26268.65.192.24.190.1177355828.squirrel@mail.jcomserv.net> Thanks. I can't find the review bug, should I just make the ownership change request on the AWOL bug? Or am I just dense? :) > On Fri, 20 Apr 2007 06:28:01 -0500 (CDT) > limb at jcomserv.net ("Jon Ciesla") wrote: > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 >> >> It has been 3 weeks with no contact. >> >> Axel Thimm (Axel.Thimm at ATrpms.net) has requested to be made the >> maintainer of both nx and freenx, pending a 3 day wait and approval >> by a FESCO member. > > I see no problems with this. It does indeed appear that the maintainer > is not reachable. ;( Don't forget to reassign those bugs when the > ownership change is made. >> >> He already has much of the needed work on these packages prepared. > > Excellent. > >> Jon Ciesla > > kevin > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From wtogami at redhat.com Mon Apr 23 19:22:22 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 Apr 2007 15:22:22 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <200704231514.50995.jkeating@redhat.com> References: <462660F6.2070909@redhat.com> <462BFC8A.4090704@redhat.com> <462D057A.30802@redhat.com> <200704231514.50995.jkeating@redhat.com> Message-ID: <462D076E.6010900@redhat.com> Jesse Keating wrote: > On Monday 23 April 2007 15:14:02 Warren Togami wrote: >> Also consider the impact on RHEL5 users, where the complaint of this bug >> originated. How do you think the non-Asian users will feel when >> RHEL-5.1 forces them to install SCIM and it is using memory always, when >> they don't need it? > > Warren, changes we make in Fedora 7 have little to no impact on RHEL5(.?) > Comps is completely forked, packages are now forked no more inheritance, > etc... I know... however we have to solve the same root problem in RHEL5. It makes no sense if we solve the problem in divergent ways. Warren From Axel.Thimm at ATrpms.net Mon Apr 23 19:27:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Apr 2007 21:27:21 +0200 Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover In-Reply-To: <26268.65.192.24.190.1177355828.squirrel@mail.jcomserv.net> References: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> <26268.65.192.24.190.1177355828.squirrel@mail.jcomserv.net> Message-ID: <20070423192721.GB28670@neu.nirvana> On Mon, Apr 23, 2007 at 02:17:08PM -0500, Jon Ciesla wrote: > Thanks. I can't find the review bug, should I just make the ownership > change request on the AWOL bug? Or am I just dense? :) I sent a mail to cvsadmins, I'm going to send you a copy. > > On Fri, 20 Apr 2007 06:28:01 -0500 (CDT) > > limb at jcomserv.net ("Jon Ciesla") wrote: > > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > >> > >> It has been 3 weeks with no contact. > >> > >> Axel Thimm (Axel.Thimm at ATrpms.net) has requested to be made the > >> maintainer of both nx and freenx, pending a 3 day wait and approval > >> by a FESCO member. > > > > I see no problems with this. It does indeed appear that the maintainer > > is not reachable. ;( Don't forget to reassign those bugs when the > > ownership change is made. > >> > >> He already has much of the needed work on these packages prepared. > > > > Excellent. > > > >> Jon Ciesla > > > > kevin > > > > > > -- 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 Mon Apr 23 19:39:24 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 23 Apr 2007 14:39:24 -0500 Subject: Spilt libperl from perl In-Reply-To: <462D0666.2000201@redhat.com> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> Message-ID: <1177357164.5956.23.camel@localhost.localdomain> On Mon, 2007-04-23 at 15:17 -0400, Warren Togami wrote: > In today's Release Engineering meeting, it was decided that the libperl > multilib conflicts are a Test4 blocker. So we need to split libperl.so > into a sub-package. I'm not going to support making a libperl subpackage to dodge fixing multilib. By doing this, we just slide down the slippery slope of avoiding the problem, and relying on dirty hacks instead of solving the hard problems. ~spot From notting at redhat.com Mon Apr 23 19:45:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Apr 2007 15:45:41 -0400 Subject: Spilt libperl from perl In-Reply-To: <1177357164.5956.23.camel@localhost.localdomain> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> Message-ID: <20070423194541.GA16904@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > In today's Release Engineering meeting, it was decided that the libperl > > multilib conflicts are a Test4 blocker. So we need to split libperl.so > > into a sub-package. > > I'm not going to support making a libperl subpackage to dodge fixing > multilib. By doing this, we just slide down the slippery slope of > avoiding the problem, and relying on dirty hacks instead of solving the > hard problems. This solves the problem for now, and we already are planning to change multilib for F8. Changing multlib for Fedora 7: 1) isn't on the feature list 2) would slip the release (due to the necessity to fix broken upgrades) 3) is after the feature freeze .. all for a whopping 6 packages in Extras that need tweaked in some way? Bill From wtogami at redhat.com Mon Apr 23 19:51:20 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 Apr 2007 15:51:20 -0400 Subject: Spilt libperl from perl In-Reply-To: <20070423194541.GA16904@nostromo.devel.redhat.com> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> Message-ID: <462D0E38.8090904@redhat.com> Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: >>> In today's Release Engineering meeting, it was decided that the libperl >>> multilib conflicts are a Test4 blocker. So we need to split libperl.so >>> into a sub-package. >> I'm not going to support making a libperl subpackage to dodge fixing >> multilib. By doing this, we just slide down the slippery slope of >> avoiding the problem, and relying on dirty hacks instead of solving the >> hard problems. > > This solves the problem for now, and we already are planning to change > multilib for F8. > Any written plans of how exactly multilib will change for F8? Warren From notting at redhat.com Mon Apr 23 19:55:26 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Apr 2007 15:55:26 -0400 Subject: Spilt libperl from perl In-Reply-To: <462D0E38.8090904@redhat.com> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> Message-ID: <20070423195526.GA17157@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > >This solves the problem for now, and we already are planning to change > >multilib for F8. > > Any written plans of how exactly multilib will change for F8? No concrete plans. One idea: - Have all repos be single-arch. Those that want multilb subscribe to both repos, and have their packages determined by a yum plugin. Pros: simple for repo creation allows users to customize what they want Cons: the plugin could take a not-insignificant amount of cpu time/ram to run probably would need some core yum changes as well Basically, there are two reasons that extensive multlib support is/was needed: 1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. #2 has historically been a problem that multlib solved. In a fully open Fedora world, it can be solved with mock (assuming we throw up a full ppc64 tree somewhere). This leaves #1. You could certainly write algorithms to determine 'what is a runtime lib' that will operate on any package set and decide what to install. But, since any such algorithm will be iterating over the file set, it's unlikely to be fast. Bill From jkeating at redhat.com Mon Apr 23 19:54:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Apr 2007 15:54:01 -0400 Subject: Spilt libperl from perl In-Reply-To: <462A6A23.5030409@redhat.com> References: <462A6A23.5030409@redhat.com> Message-ID: <200704231554.02102.jkeating@redhat.com> On Saturday 21 April 2007 15:46:43 Warren Togami wrote: > During the last FESCO meeting there was (reluctant?) agreement that > splitting libperl.so from perl would be a better solution to workaround > our broken multilib policy than to split perl sub-packages out of > everything that breaks due to perl.i386 being removed from F7 x86-64. > > Is this going to happen? Ok, this is my huge mistake. Here is what happened. In FC6, perl was multilib because gaim brought it in during tree builds. Gaim being multilib. Recently, gaim went away and pidgin showed up in Extras. All of a sudden, nothing brought in perl to be multilib. I mistakenly assumed that perl had never been multilib and things were just noticing. We had big discussions around perl/gaim and multilib around FC6 release time and I forgot the outcome, and I simply was an idiot and didn't look at the FC6 tree, which clearly shows perl was multilib. To resolve this, I have added perl to a "whitelist" to force it to be multilib again, since pidgin isn't in core to pull it in. This will resolve all these broken deps for Fedora 7, without making further drastic changes to the perl package. Perl should once again be multilib with tonight's rawhide. This problem wouldn't have come up had we already been merged, since pidgin would be available during the compose, depsolved, and brought in the perl multilib. -- 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 j.w.r.degoede at hhs.nl Mon Apr 23 20:21:03 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Apr 2007 22:21:03 +0200 Subject: Spilt libperl from perl In-Reply-To: <20070423195526.GA17157@nostromo.devel.redhat.com> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> Message-ID: <462D152F.7060607@hhs.nl> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: >>> This solves the problem for now, and we already are planning to change >>> multilib for F8. >> Any written plans of how exactly multilib will change for F8? > > No concrete plans. One idea: > > - Have all repos be single-arch. Those that want multilb subscribe to both > repos, and have their packages determined by a yum plugin. > > Pros: simple for repo creation > allows users to customize what they want > > Cons: the plugin could take a not-insignificant amount of cpu time/ram to run > probably would need some core yum changes as well > > Basically, there are two reasons that extensive multlib support is/was > needed: > > 1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64 > > 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. > > #2 has historically been a problem that multlib solved. In a fully open > Fedora world, it can be solved with mock (assuming we throw up a full > ppc64 tree somewhere). > Actually 2 is a problem that multilib doesn't solve, I've written some scripts / hacks to be able to build i386 on x86_64 without using mock because I have a slow link and thus mock used to take eons, now it only takes ages (--autocache rules!). However these scripts were a big hack, and even with this big hack things didn't always work properly. Using mock is the only sane way to build i386 packages on an x86_64 install. > This leaves #1. You could certainly write algorithms to determine 'what > is a runtime lib' that will operate on any package set and decide what > to install. But, since any such algorithm will be iterating over the file > set, it's unlikely to be fast. > Yes 1 is a very important reason to have multilib support, actually the only reason if you ask me, because as said 2 is seriously broken. So I think any new multilib strategy should solely target 1. Regards, Hans From pertusus at free.fr Mon Apr 23 20:03:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Apr 2007 22:03:01 +0200 Subject: Spilt libperl from perl In-Reply-To: <462D152F.7060607@hhs.nl> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> Message-ID: <20070423200300.GB2874@free.fr> On Mon, Apr 23, 2007 at 10:21:03PM +0200, Hans de Goede wrote: > > Actually 2 is a problem that multilib doesn't solve, I've written some > scripts / hacks to be able to build i386 on x86_64 without using mock > because I have a slow link and thus mock used to take eons, now it only > takes ages (--autocache rules!). However these scripts were a big hack, and > even with this big hack things didn't always work properly. Using mock is > the only sane way to build i386 packages on an x86_64 install. I am not very knowledgable in those issues, but what about those who just want to do a ./configure with the right flags/environemnt vars to specifically build an i386 package in an x86_64 install. -- Pat From katzj at redhat.com Mon Apr 23 20:18:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 23 Apr 2007 16:18:45 -0400 Subject: Spilt libperl from perl In-Reply-To: <462D152F.7060607@hhs.nl> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> Message-ID: <1177359525.26730.27.camel@aglarond.local> On Mon, 2007-04-23 at 22:21 +0200, Hans de Goede wrote: > Bill Nottingham wrote: > > 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. > > > > #2 has historically been a problem that multlib solved. In a fully open > > Fedora world, it can be solved with mock (assuming we throw up a full > > ppc64 tree somewhere). > > > Actually 2 is a problem that multilib doesn't solve, I've written some scripts > / hacks to be able to build i386 on x86_64 without using mock because I have a > slow link and thus mock used to take eons, now it only takes ages (--autocache > rules!). However these scripts were a big hack, and even with this big hack > things didn't always work properly. Using mock is the only sane way to build > i386 packages on an x86_64 install. That's only true if the world revolves around developing packages. If I'm a software developer writing and testing software, it works quite nicely. I have a checkout of anaconda, I run make and it builds for x86_64. If I have a need to test something or see something on i386, I just have to ensure that -m32 is in my CFLAGS/LDFLAGS and can use the same environment. And then copy over the shared object into where I'm testing or whatever happens to be needed for that case. And the above holds true for a *LOT* of software. If I'm using something with pkg-config, I have to also set its appropriate environment variable. And similarly pass the right args to configure for autofoolery. Building packages is an entirely different ball of wax. And part of the problem there is more bugs in the implementation with RPM than anything else.[1] Jeremy [1] And some of the changes in jbj's rpm 4.4.8 actually help in this area, but I'm not sure that they solve everything From j.w.r.degoede at hhs.nl Mon Apr 23 20:36:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Apr 2007 22:36:36 +0200 Subject: Spilt libperl from perl In-Reply-To: <20070423200300.GB2874@free.fr> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> Message-ID: <462D18D4.5030403@hhs.nl> Patrice Dumas wrote: > On Mon, Apr 23, 2007 at 10:21:03PM +0200, Hans de Goede wrote: >> Actually 2 is a problem that multilib doesn't solve, I've written some >> scripts / hacks to be able to build i386 on x86_64 without using mock >> because I have a slow link and thus mock used to take eons, now it only >> takes ages (--autocache rules!). However these scripts were a big hack, and >> even with this big hack things didn't always work properly. Using mock is >> the only sane way to build i386 packages on an x86_64 install. > > I am not very knowledgable in those issues, but what about those who > just want to do a ./configure with the right flags/environemnt vars > to specifically build an i386 package in an x86_64 install. > That won't work unless you're really really lucky, most configure scripts and makefiles are not written with this in mind, and thus fail miserably. Also things like pkg-config for example will still look under /usr/lib64/pkgconfig even when run with/through setarch i386. Regards, Hans From j.w.r.degoede at hhs.nl Mon Apr 23 20:41:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Apr 2007 22:41:53 +0200 Subject: Spilt libperl from perl In-Reply-To: <1177359525.26730.27.camel@aglarond.local> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <1177359525.26730.27.camel@aglarond.local> Message-ID: <462D1A11.3080904@hhs.nl> Jeremy Katz wrote: > On Mon, 2007-04-23 at 22:21 +0200, Hans de Goede wrote: >> Bill Nottingham wrote: >>> 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. >>> >>> #2 has historically been a problem that multlib solved. In a fully open >>> Fedora world, it can be solved with mock (assuming we throw up a full >>> ppc64 tree somewhere). >>> >> Actually 2 is a problem that multilib doesn't solve, I've written some scripts >> / hacks to be able to build i386 on x86_64 without using mock because I have a >> slow link and thus mock used to take eons, now it only takes ages (--autocache >> rules!). However these scripts were a big hack, and even with this big hack >> things didn't always work properly. Using mock is the only sane way to build >> i386 packages on an x86_64 install. > > That's only true if the world revolves around developing packages. If > I'm a software developer writing and testing software, it works quite > nicely. I have a checkout of anaconda, I run make and it builds for > x86_64. If I have a need to test something or see something on i386, I > just have to ensure that -m32 is in my CFLAGS/LDFLAGS and can use the > same environment. And then copy over the shared object into where I'm > testing or whatever happens to be needed for that case. > > And the above holds true for a *LOT* of software. If I'm using > something with pkg-config, I have to also set its appropriate > environment variable. And similarly pass the right args to configure > for autofoolery. > Have you actually tried this? I agree that if you've software with a simple straight forward makefile then it might work, and thus that it could work for software you develop yourself. But it doesn't hold true for a *LOT* of software. There are just to many hacks in Makefile's / configure / scons / whatever build files which break. If you want reproducable results using an i386 chroot really seems to be the best way to develop i386 on x86_64. > Building packages is an entirely different ball of wax. And part of the > problem there is more bugs in the implementation with RPM than anything > else.[1] > Actually when trying this rpm was the least of my problems, its funky things like checking for the existence of /lib64 and then always install the libs there, etc, etc. Regards, Hans From pertusus at free.fr Mon Apr 23 20:24:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 23 Apr 2007 22:24:36 +0200 Subject: Spilt libperl from perl In-Reply-To: <462D18D4.5030403@hhs.nl> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> Message-ID: <20070423202436.GD2874@free.fr> On Mon, Apr 23, 2007 at 10:36:36PM +0200, Hans de Goede wrote: > > That won't work unless you're really really lucky, most configure scripts > and makefiles are not written with this in mind, and thus fail miserably. > > Also things like pkg-config for example will still look under > /usr/lib64/pkgconfig even when run with/through setarch i386. The case I have in mind is not somebody taking a random project and trying to use i386 libs, but more somebody with knowledge of the software he is using, and ready to modify the configure scripts and makefiles for this kind of multilib development. I think that it should be possible for such a user to achieve developping i386 stuff on x86_64 without resorting to installing thinigs by hand or using a chroot. -- Pat From katzj at redhat.com Mon Apr 23 20:32:44 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 23 Apr 2007 16:32:44 -0400 Subject: Spilt libperl from perl In-Reply-To: <462D1A11.3080904@hhs.nl> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <1177359525.26730.27.camel@aglarond.local> <462D1A11.3080904@hhs.nl> Message-ID: <1177360364.26730.33.camel@aglarond.local> On Mon, 2007-04-23 at 22:41 +0200, Hans de Goede wrote: > Jeremy Katz wrote: > > On Mon, 2007-04-23 at 22:21 +0200, Hans de Goede wrote: > >> Bill Nottingham wrote: > >>> 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. > >>> > >>> #2 has historically been a problem that multlib solved. In a fully open > >>> Fedora world, it can be solved with mock (assuming we throw up a full > >>> ppc64 tree somewhere). > >>> > >> Actually 2 is a problem that multilib doesn't solve, I've written some scripts > >> / hacks to be able to build i386 on x86_64 without using mock because I have a > >> slow link and thus mock used to take eons, now it only takes ages (--autocache > >> rules!). However these scripts were a big hack, and even with this big hack > >> things didn't always work properly. Using mock is the only sane way to build > >> i386 packages on an x86_64 install. > > > > That's only true if the world revolves around developing packages. If > > I'm a software developer writing and testing software, it works quite > > nicely. I have a checkout of anaconda, I run make and it builds for > > x86_64. If I have a need to test something or see something on i386, I > > just have to ensure that -m32 is in my CFLAGS/LDFLAGS and can use the > > same environment. And then copy over the shared object into where I'm > > testing or whatever happens to be needed for that case. > > > > And the above holds true for a *LOT* of software. If I'm using > > something with pkg-config, I have to also set its appropriate > > environment variable. And similarly pass the right args to configure > > for autofoolery. > > > Have you actually tried this? I agree that if you've software with a simple > straight forward makefile then it might work, and thus that it could work for > software you develop yourself. But it doesn't hold true for a *LOT* of software. I've tried it on a fair bit of stuff. And while there are cases where things break (at which point, they're usually pretty straight-forward to fix and send patches), things _are_ getting quite a bit better. Jeremy From Axel.Thimm at ATrpms.net Mon Apr 23 19:29:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 23 Apr 2007 21:29:23 +0200 Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover In-Reply-To: <20070423192721.GB28670@neu.nirvana> References: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> <26268.65.192.24.190.1177355828.squirrel@mail.jcomserv.net> <20070423192721.GB28670@neu.nirvana> Message-ID: <20070423192923.GC28670@neu.nirvana> On Mon, Apr 23, 2007 at 09:27:21PM +0200, Axel Thimm wrote: > On Mon, Apr 23, 2007 at 02:17:08PM -0500, Jon Ciesla wrote: > > Thanks. I can't find the review bug, should I just make the ownership > > change request on the AWOL bug? Or am I just dense? :) > > I sent a mail to cvsadmins, I'm going to send you a copy. Hm, the mail to cvsadmins bounced back, looks like the mail alias was removed/renamed since I last used it :/ > > > On Fri, 20 Apr 2007 06:28:01 -0500 (CDT) > > > limb at jcomserv.net ("Jon Ciesla") wrote: > > > > > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234619 > > >> > > >> It has been 3 weeks with no contact. > > >> > > >> Axel Thimm (Axel.Thimm at ATrpms.net) has requested to be made the > > >> maintainer of both nx and freenx, pending a 3 day wait and approval > > >> by a FESCO member. > > > > > > I see no problems with this. It does indeed appear that the maintainer > > > is not reachable. ;( Don't forget to reassign those bugs when the > > > ownership change is made. > > >> > > >> He already has much of the needed work on these packages prepared. > > > > > > Excellent. > > > > > >> Jon Ciesla > > > > > > kevin > > > > > > > > > > > -- 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 jwboyer at jdub.homelinux.org Mon Apr 23 20:32:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 23 Apr 2007 15:32:39 -0500 Subject: Spilt libperl from perl In-Reply-To: <462D1A11.3080904@hhs.nl> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <1177359525.26730.27.camel@aglarond.local> <462D1A11.3080904@hhs.nl> Message-ID: <1177360359.3471.6.camel@zod.rchland.ibm.com> On Mon, 2007-04-23 at 22:41 +0200, Hans de Goede wrote: > > > > That's only true if the world revolves around developing packages. If > > I'm a software developer writing and testing software, it works quite > > nicely. I have a checkout of anaconda, I run make and it builds for > > x86_64. If I have a need to test something or see something on i386, I > > just have to ensure that -m32 is in my CFLAGS/LDFLAGS and can use the > > same environment. And then copy over the shared object into where I'm > > testing or whatever happens to be needed for that case. > > > > And the above holds true for a *LOT* of software. If I'm using > > something with pkg-config, I have to also set its appropriate > > environment variable. And similarly pass the right args to configure > > for autofoolery. > > > > Have you actually tried this? I agree that if you've software with a simple > straight forward makefile then it might work, and thus that it could work for > software you develop yourself. But it doesn't hold true for a *LOT* of software. Sounds like bugs in that software to me... josh From bugs.michael at gmx.net Mon Apr 23 20:42:29 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 23 Apr 2007 22:42:29 +0200 Subject: Spilt libperl from perl In-Reply-To: <20070423194541.GA16904@nostromo.devel.redhat.com> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> Message-ID: <20070423224229.725fe7a3.bugs.michael@gmx.net> On Mon, 23 Apr 2007 15:45:41 -0400, Bill Nottingham wrote: > This solves the problem for now, and we already are planning to change > multilib for F8. > > Changing multlib for Fedora 7: > 1) isn't on the feature list > 2) would slip the release (due to the necessity to fix broken upgrades) > 3) is after the feature freeze > > > .. all for a whopping 6 packages in Extras that need tweaked in some way? wrt 2) why? Apparently, removing perl.i386 in Core has not broken any package in Core. And the few in Extras 7 have been put onto the multi-lib blacklist. Since Extras 6 does not contain any multilib packages except for "wine" and its deps, there is no broken upgrade path. Or where is it? From notting at redhat.com Mon Apr 23 20:43:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 23 Apr 2007 16:43:42 -0400 Subject: Spilt libperl from perl In-Reply-To: <20070423224229.725fe7a3.bugs.michael@gmx.net> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <20070423224229.725fe7a3.bugs.michael@gmx.net> Message-ID: <20070423204342.GA18053@nostromo.devel.redhat.com> Michael Schwendt (bugs.michael at gmx.net) said: > > This solves the problem for now, and we already are planning to change > > multilib for F8. > > > > Changing multlib for Fedora 7: > > 1) isn't on the feature list > > 2) would slip the release (due to the necessity to fix broken upgrades) > > 3) is after the feature freeze > > > > > > .. all for a whopping 6 packages in Extras that need tweaked in some way? > > wrt 2) why? Apparently, removing perl.i386 in Core has not broken > any package in Core. And the few in Extras 7 have been put onto the > multi-lib blacklist. Since Extras 6 does not contain any multilib > packages except for "wine" and its deps, there is no broken > upgrade path. Or where is it? Changing how multilib is done *everywhere* will break upgrades if the package set changes. Bill From dwmw2 at infradead.org Mon Apr 23 20:48:59 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 23 Apr 2007 21:48:59 +0100 (BST) Subject: Spilt libperl from perl In-Reply-To: <1177357164.5956.23.camel@localhost.localdomain> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> Message-ID: On Mon, 23 Apr 2007, Tom \"spot\" Callaway wrote: > On Mon, 2007-04-23 at 15:17 -0400, Warren Togami wrote: >> In today's Release Engineering meeting, it was decided that the libperl >> multilib conflicts are a Test4 blocker. So we need to split libperl.so >> into a sub-package. > > I'm not going to support making a libperl subpackage to dodge fixing > multilib. By doing this, we just slide down the slippery slope of > avoiding the problem, and relying on dirty hacks instead of solving the > hard problems. The dirty hack is what we have at the moment -- splitting the package is the fix for it. Currently, yum or the user chooses which packages to install -- and then RPM makes its own decisions about which files to use from those packages, where there are conflicts in /usr/bin. Not only does that leave the decision being made in two separate places, but RPM also gets it _wrong_ (at least when it chooses 64-bit executables on ppc64 and sparc64). It makes a lot of sense to say that we shouldn't have those file conflicts. Allowing conflicting files and letting RPM 'choose' one of them is the dirty hack. Fixing the packages to remove those conflicts is the fix. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235757 -- dwmw2 From bugs.michael at gmx.net Mon Apr 23 20:50:53 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 23 Apr 2007 22:50:53 +0200 Subject: Spilt libperl from perl In-Reply-To: <200704231554.02102.jkeating@redhat.com> References: <462A6A23.5030409@redhat.com> <200704231554.02102.jkeating@redhat.com> Message-ID: <20070423225053.e4df97d4.bugs.michael@gmx.net> On Mon, 23 Apr 2007 15:54:01 -0400, Jesse Keating wrote: > Recently, gaim went away and pidgin showed up in Extras. All of a sudden, > nothing brought in perl to be multilib. I mistakenly assumed that perl had > never been multilib and things were just noticing. We had big discussions > around perl/gaim and multilib around FC6 release time and I forgot the > outcome, and I simply was an idiot and didn't look at the FC6 tree, which > clearly shows perl was multilib. > > To resolve this, I have added perl to a "whitelist" to force it to be multilib > again, since pidgin isn't in core to pull it in. This will resolve all these > broken deps for Fedora 7, without making further drastic changes to the perl > package. > > Perl should once again be multilib with tonight's rawhide. Hmmm ... recently you've said it (Perl multi-lib) doesn't work at all. > This problem wouldn't have come up had we already been merged, since pidgin > would be available during the compose, depsolved, and brought in the perl > multilib. Pidgin introduces a full new set of packages, which replace/obsolete the old gaim packages. Isn't that enough to upgrade from an old fc6 multi-lib gaim to the fc7 64-bit pidgin? From mszpak at wp.pl Mon Apr 23 21:18:23 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Mon, 23 Apr 2007 23:18:23 +0200 Subject: A small problem with cvs-import.sh Message-ID: <462D229F.8040809@wp.pl> Hi, I added a new package to CVS today and experienced problem with cvs-import.sh script. After "cvs-import.sh mysrps" sources file was added to a devel directory, but there wasn't a .spec file. I tried to add it manually, but I've got info that it was already added by "third party". In fact file was there, but I had to fetch it from a repository manually (by "cvs update"). Should cvs-import.sh fetch this file (and probably patches too - I didn't have any patch, so don't know if it does it) from a repository? If not I think that "Step 10" in http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess should be extended. Btw, tag which was created in the import process was named "pyxattr-0_2_1-3". Shouldn't it be "pyxattr-0_2_1-3_fc7" (which is created after "make tag" in a devel directory)? Regards Marcin From Christian.Iseli at licr.org Mon Apr 23 21:50:28 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 23 Apr 2007 23:50:28 +0200 Subject: Spilt libperl from perl In-Reply-To: <20070423195526.GA17157@nostromo.devel.redhat.com> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> Message-ID: <20070423235028.2d34d363@ludwig-alpha.unil.ch> On Mon, 23 Apr 2007 15:55:26 -0400, Bill Nottingham wrote: > No concrete plans. One idea: > > - Have all repos be single-arch. Those that want multilb subscribe to both > repos, and have their packages determined by a yum plugin. Yea, I like that idea too. C From kevin at tummy.com Mon Apr 23 23:00:56 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 23 Apr 2007 17:00:56 -0600 Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover In-Reply-To: <20070423192923.GC28670@neu.nirvana> References: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> <26268.65.192.24.190.1177355828.squirrel@mail.jcomserv.net> <20070423192721.GB28670@neu.nirvana> <20070423192923.GC28670@neu.nirvana> Message-ID: <20070423170056.703d930d@ghistelwchlohm.scrye.com> On Mon, 23 Apr 2007 21:29:23 +0200 Axel.Thimm at ATrpms.net (Axel Thimm) wrote: > On Mon, Apr 23, 2007 at 09:27:21PM +0200, Axel Thimm wrote: > > On Mon, Apr 23, 2007 at 02:17:08PM -0500, Jon Ciesla wrote: > > > Thanks. I can't find the review bug, should I just make the > > > ownership change request on the AWOL bug? Or am I just dense? :) > > > > I sent a mail to cvsadmins, I'm going to send you a copy. > > Hm, the mail to cvsadmins bounced back, looks like the mail alias was > removed/renamed since I last used it :/ Yeah, this package was added back in 2005 before the formal review procedures were in place. ;( How about you just use the AWOL bug? I think cvsadmins at fedoraproject dot org should work as an alias tho. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Apr 23 23:17:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Apr 2007 19:17:15 -0400 Subject: Spilt libperl from perl In-Reply-To: <20070423225053.e4df97d4.bugs.michael@gmx.net> References: <462A6A23.5030409@redhat.com> <200704231554.02102.jkeating@redhat.com> <20070423225053.e4df97d4.bugs.michael@gmx.net> Message-ID: <200704231917.16147.jkeating@redhat.com> On Monday 23 April 2007 16:50:53 Michael Schwendt wrote: > > Perl should once again be multilib with tonight's rawhide. > > Hmmm ... recently you've said it (Perl multi-lib) doesn't work at all. Perl the interpreter won't necessarily, but it appears libperl.so did work as multilib, or at least it let deps resolve and nobody has noticed that it didn't work. > > This problem wouldn't have come up had we already been merged, since > > pidgin would be available during the compose, depsolved, and brought in > > the perl multilib. > > Pidgin introduces a full new set of packages, which replace/obsolete the > old gaim packages. Isn't that enough to upgrade from an old fc6 multi-lib > gaim to the fc7 64-bit pidgin? I don't have a ton of faith in things correctly going from multilib to non-multilib and having the obsoletes do the right thing. Given we're at test4, I'm going for the least intrusive change, which is to make perl. [i386,ppc64] show up in the i386/ppc repos. -- 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 jwboyer at jdub.homelinux.org Mon Apr 23 23:46:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 23 Apr 2007 18:46:27 -0500 Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover In-Reply-To: <20070423170056.703d930d@ghistelwchlohm.scrye.com> References: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> <26268.65.192.24.190.1177355828.squirrel@mail.jcomserv.net> <20070423192721.GB28670@neu.nirvana> <20070423192923.GC28670@neu.nirvana> <20070423170056.703d930d@ghistelwchlohm.scrye.com> Message-ID: <1177371988.25513.86.camel@vader.jdub.homelinux.org> On Mon, 2007-04-23 at 17:00 -0600, Kevin Fenzi wrote: > On Mon, 23 Apr 2007 21:29:23 +0200 > Axel.Thimm at ATrpms.net (Axel Thimm) wrote: > > > On Mon, Apr 23, 2007 at 09:27:21PM +0200, Axel Thimm wrote: > > > On Mon, Apr 23, 2007 at 02:17:08PM -0500, Jon Ciesla wrote: > > > > Thanks. I can't find the review bug, should I just make the > > > > ownership change request on the AWOL bug? Or am I just dense? :) > > > > > > I sent a mail to cvsadmins, I'm going to send you a copy. > > > > Hm, the mail to cvsadmins bounced back, looks like the mail alias was > > removed/renamed since I last used it :/ > > Yeah, this package was added back in 2005 before the formal review > procedures were in place. ;( > > How about you just use the AWOL bug? > > I think cvsadmins at fedoraproject dot org should work as an alias tho. Huh? Wah? What needs CVS admining? Easiest way is to just open a bug against the package and set the flag. josh From a.badger at gmail.com Tue Apr 24 03:53:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 23 Apr 2007 20:53:27 -0700 Subject: [Guidelines Update] Overall Responsibilities Message-ID: <1177386807.6791.27.camel@localhost.localdomain> The Packaging Guidelines have been updated with this statement of overall responsiblity. It's purpose is to clearly state the relationship between the packager, reviewer, and the packaging 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. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee. ''' -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 Axel.Thimm at ATrpms.net Tue Apr 24 05:40:44 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Apr 2007 07:40:44 +0200 Subject: NX/FreeNX maintainer: AWOL: Formal request for takeover In-Reply-To: <20070423170056.703d930d@ghistelwchlohm.scrye.com> References: <20066.65.192.24.190.1177068481.squirrel@mail.jcomserv.net> <20070423130510.1c5cd724@ghistelwchlohm.scrye.com> <26268.65.192.24.190.1177355828.squirrel@mail.jcomserv.net> <20070423192721.GB28670@neu.nirvana> <20070423192923.GC28670@neu.nirvana> <20070423170056.703d930d@ghistelwchlohm.scrye.com> Message-ID: <20070424054044.GE633@neu.nirvana> On Mon, Apr 23, 2007 at 05:00:56PM -0600, Kevin Fenzi wrote: > On Mon, 23 Apr 2007 21:29:23 +0200 > Axel.Thimm at ATrpms.net (Axel Thimm) wrote: > > > On Mon, Apr 23, 2007 at 09:27:21PM +0200, Axel Thimm wrote: > > > On Mon, Apr 23, 2007 at 02:17:08PM -0500, Jon Ciesla wrote: > > > > Thanks. I can't find the review bug, should I just make the > > > > ownership change request on the AWOL bug? Or am I just dense? :) > > > > > > I sent a mail to cvsadmins, I'm going to send you a copy. > > > > Hm, the mail to cvsadmins bounced back, looks like the mail alias was > > removed/renamed since I last used it :/ > > Yeah, this package was added back in 2005 before the formal review > procedures were in place. ;( > > How about you just use the AWOL bug? > > I think cvsadmins at fedoraproject dot org should work as an alias tho. That was the alias I was talking about. Looks like it's been withdrawn in favour of the bugzilla method. -- 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 24 06:17:19 2007 From: petersen at redhat.com (Jens Petersen) Date: Tue, 24 Apr 2007 16:17:19 +1000 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <462D057A.30802@redhat.com> References: <462660F6.2070909@redhat.com> <462BFC8A.4090704@redhat.com> <462D057A.30802@redhat.com> Message-ID: <462DA0EF.80504@redhat.com> Warren Togami wrote: > - If you are in the extreme minority that needs non-default behavior, it > is perfectly reasonable to expect these users to choose a custom > setting. It doesn't make sense to inconvenience the majority of users > to make it slightly simpler for these rare users. I'm not sure about "extreme minority", but I am not looking forward to field bug reports and mails asking if and how to enable scim. > - These rare users already have to enable it with a non-default > configuration in other operating systems. This is nothing new, and I > would disagree that this is a regression. Still looks a bit like one to me. The alternatives I can see are: 1) not installing scim by default 2) only starting scim by default if scim IMEs are installed 3) use provides/requires to pull in scim im modules though they do not address the livecd. > Also consider the impact on RHEL5 users, where the complaint of this bug > originated. How do you think the non-Asian users will feel when > RHEL-5.1 forces them to install SCIM and it is using memory always, when > they don't need it? IMHO we should not install scim by default in 5.1. > Sorry, this was considered a Test4 blocker so I have already reverted it > a few days ago. You might want to check that it was backed out properly. Yes, I noticed that after sending. I'll update scim later since the changes should actually be in the system config file not the hardcoded default. (I was expecting bug reports if the previous version had stayed in test4 so thanks for sparing me those, though some of them might have been useful...) > For example, Desktop team would like eventually more tightly integrate > SCIM activation/configuration with GNOME's session and capplets. This > would enable activation of SCIM during any running session instead of > requiring a desktop relog. There are opportunities to improve our > default launch behavior in conjunction with this. Yes, indeed this of course is the real long term solution and something I would really like to help make happen too. It really needs to be done upstream together with the freedesktop and input method communities. Thanks, Jens From rc040203 at freenet.de Tue Apr 24 06:48:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Apr 2007 08:48:59 +0200 Subject: Spilt libperl from perl In-Reply-To: <1177357164.5956.23.camel@localhost.localdomain> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> Message-ID: <1177397339.30803.205.camel@mccallum.corsepiu.local> On Mon, 2007-04-23 at 14:39 -0500, Tom "spot" Callaway wrote: > On Mon, 2007-04-23 at 15:17 -0400, Warren Togami wrote: > > > In today's Release Engineering meeting, it was decided that the libperl > > multilib conflicts are a Test4 blocker. So we need to split libperl.so > > into a sub-package. > > I'm not going to support making a libperl subpackage to dodge fixing > multilib. Neither do I. > By doing this, we just slide down the slippery slope of > avoiding the problem, and relying on dirty hacks instead of solving the > hard problems. libperl.so already is being installed into a multilib'ed directory. .../i386-*/.../libperl.so So whatever the problem is, it is not multilibs nor perl. Ralf From dwmw2 at infradead.org Tue Apr 24 09:42:49 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 24 Apr 2007 10:42:49 +0100 Subject: Spilt libperl from perl In-Reply-To: <200704231917.16147.jkeating@redhat.com> References: <462A6A23.5030409@redhat.com> <200704231554.02102.jkeating@redhat.com> <20070423225053.e4df97d4.bugs.michael@gmx.net> <200704231917.16147.jkeating@redhat.com> Message-ID: <1177407769.2755.81.camel@pmac.infradead.org> On Mon, 2007-04-23 at 19:17 -0400, Jesse Keating wrote: > I don't have a ton of faith in things correctly going from multilib to > non-multilib and having the obsoletes do the right thing. Given we're at > test4, I'm going for the least intrusive change, which is to make perl. > [i386,ppc64] show up in the i386/ppc repos. So we'll get 64-bit /usr/bin/perl, and none of the 32-bit perl modules (which aren't even _shipped_ 64-bit on ppc) will work. Please don't just do that. Please apply the _correct_ fix, which is to split the package so that you can have both versions of libperl, but only the primary architecture version of the binaries. -- dwmw2 From dwmw2 at infradead.org Tue Apr 24 10:26:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 24 Apr 2007 11:26:46 +0100 Subject: Spilt libperl from perl In-Reply-To: <20070423195526.GA17157@nostromo.devel.redhat.com> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> Message-ID: <1177410406.2755.117.camel@pmac.infradead.org> On Mon, 2007-04-23 at 15:55 -0400, Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: > > Any written plans of how exactly multilib will change for F8? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=multilib https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib > No concrete plans. One idea: > > - Have all repos be single-arch. Those that want multilb subscribe to both > repos, and have their packages determined by a yum plugin. Amen. It would be nice if we could have them subscribe to the _normal_ i386 repo -- rather than having a separate repo with just a subset of packages. The whole crappy 'has a -devel subpackage' heuristic can just die, but this works _ONLY_ if we fix the tools to do the right thing when the full set of secondary-arch packages is available. For a start, that means fixing yum to refrain from installing both versions when asked for packages by name. It should install only the primary arch unless explicitly asked to do otherwise. I think that's the same as bug #235756 which is filed against the installer. Should it be moved to yum? Secondly, we should kill the dirty hack in RPM which allows packages with file conflicts in /usr/bin to be installed, with RPM silently choosing one of the available files. The decision about what to install should come from whatever's calling RPM; RPM shouldn't be second-guessing. We should fix our packaging so that these file conflicts don't exist -- packages with libraries which make sense on the secondary arch should not also have executables in the same subpackage. Bug #235757 covers this, as does the subject line of this thread. We _might_ get away with just fixing RPM so that it generally does make the right decision (in particular, installing 32-bit executables on ppc64 and sparc64). But that's a crappy workaround typical of the kind of half-arsed crap we've done for multilib in the past; RPM itself is the wrong place to make such a decision. It lives at a higher level. However, 'fixing' RPM might be the easiest option before F7, to fix the perl breakage we've just introduced again -- but it's certainly not the right answer in the long term. > Pros: simple for repo creation > allows users to customize what they want > > Cons: the plugin could take a not-insignificant amount of cpu time/ram to run > probably would need some core yum changes as well I don't understand this plugin. What would it actually do? If someone _wants_ something for the secondary arch, they'll install it manually -- 'yum install firefox.i386', or 'yum install gdb.ppc64'. > Basically, there are two reasons that extensive multlib support is/was > needed: > > 1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64 > > 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. > > #2 has historically been a problem that multlib solved. In a fully open > Fedora world, it can be solved with mock (assuming we throw up a full > ppc64 tree somewhere). Multilib hasn't actually solved it very reliably, in a world where so many people make the mistake of using autoconf. I believe that pkg-config, in particular, will also always get it wrong. (Bug #224037) Mock solves it for packages, and yum's 'installroot' option can do it for random other builds if necessary. > This leaves #1. You could certainly write algorithms to determine 'what > is a runtime lib' that will operate on any package set and decide what > to install. But, since any such algorithm will be iterating over the file > set, it's unlikely to be fast. Again I think I'm missing something. We already have algorithms which handle dependencies on runtime libs. If I 'yum install gdb.ppc64' on a clean system where I've already done 'yum remove glibc.ppc64' to get rid of all that unwanted crap in the default install, it knows that it needs to install ncurses.ppc64 and glibc.ppc64. What do we need that's new? The only problem I'm aware of with dependencies is the _manual_ deps, where a package 'foo-devel' might say that it requires 'bar-devel', but in fact it should require 'bar-devel.%{ARCH}'. Because otherwise you get stuff like pango-devel.i386 being satisfied by the existence of cairo-devel.x86_64. Which doesn't actually work when you come to build it. Bug #235755. -- dwmw2 From pertusus at free.fr Tue Apr 24 11:31:42 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 24 Apr 2007 13:31:42 +0200 Subject: Spilt libperl from perl In-Reply-To: <1177410406.2755.117.camel@pmac.infradead.org> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <1177410406.2755.117.camel@pmac.infradead.org> Message-ID: <20070424113142.GF2967@free.fr> On Tue, Apr 24, 2007 at 11:26:46AM +0100, David Woodhouse wrote: > > Secondly, we should kill the dirty hack in RPM which allows packages > with file conflicts in /usr/bin to be installed, with RPM silently > choosing one of the available files. The decision about what to install > should come from whatever's calling RPM; RPM shouldn't be > second-guessing. We should fix our packaging so that these file > conflicts don't exist -- packages with libraries which make sense on the > secondary arch should not also have executables in the same subpackage. > Bug #235757 covers this, as does the subject line of this thread. This should certainly also be considered by FESCo and the packaging commitee: if it enters the guidelines it should be fairly easy to push packagers to fix their packages -- even before binaries conflict. > > 1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64 > > > > 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. > > > > #2 has historically been a problem that multlib solved. In a fully open > > Fedora world, it can be solved with mock (assuming we throw up a full > > ppc64 tree somewhere). > > Multilib hasn't actually solved it very reliably, in a world where so > many people make the mistake of using autoconf. I believe that > pkg-config, in particular, will also always get it wrong. (Bug #224037) I don't think autoconf itself is a show stopper. And anyway these are bugs outside of fedora (ie upstream). Allowing people to develop i386 apps on a x86_64 box would help solving thoses issues. I don't think we should force developpers to use chroots for building normal packages on fedora, but instead leave them the choice, be it only to leave them the opportunity to fix their packages to build right in multilib environment and be able to spot bugs in the tools (like pkgconfig issues). -- Pat From dwmw2 at infradead.org Tue Apr 24 11:52:04 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 24 Apr 2007 12:52:04 +0100 Subject: Spilt libperl from perl In-Reply-To: <20070424113142.GF2967@free.fr> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <1177410406.2755.117.camel@pmac.infradead.org> <20070424113142.GF2967@free.fr> Message-ID: <1177415524.2755.125.camel@pmac.infradead.org> On Tue, 2007-04-24 at 13:31 +0200, Patrice Dumas wrote: > On Tue, Apr 24, 2007 at 11:26:46AM +0100, David Woodhouse wrote: > > We should fix our packaging so that these file conflicts don't exist > > Bug #235757 covers this, as does the subject line of this thread. > > This should certainly also be considered by FESCo and the packaging > commitee: if it enters the guidelines it should be fairly easy to push > packagers to fix their packages -- even before binaries conflict. We can probably also make RPM notice this when the package is created. If a package provides a file in /usr/lib64 and a file in /usr/bin, then it's a fairly safe bet that the 32-bit version of that same package will conflict with it. > I don't think autoconf itself is a show stopper. And anyway these are > bugs outside of fedora (ie upstream). Allowing people to develop i386 > apps on a x86_64 box would help solving thoses issues. I don't think we > should force developpers to use chroots for building normal packages > on fedora, but instead leave them the choice, be it only to leave them > the opportunity to fix their packages to build right in multilib > environment and be able to spot bugs in the tools (like pkgconfig > issues). I agree. They should have the _option_ of installing all the wrong-arch development stuff and debugging the resulting autocrap and pkg-config problems, if they like that kind of pain. I'm just saying that we shouldn't install all that wrong-arch stuff by _default_. -- dwmw2 From j.w.r.degoede at hhs.nl Tue Apr 24 12:58:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 24 Apr 2007 14:58:23 +0200 Subject: Spilt libperl from perl In-Reply-To: <1177410406.2755.117.camel@pmac.infradead.org> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <1177410406.2755.117.camel@pmac.infradead.org> Message-ID: <462DFEEF.9000109@hhs.nl> David Woodhouse wrote: > On Mon, 2007-04-23 at 15:55 -0400, Bill Nottingham wrote: >> Warren Togami (wtogami at redhat.com) said: >>> Any written plans of how exactly multilib will change for F8? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=multilib > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib > >> No concrete plans. One idea: >> >> - Have all repos be single-arch. Those that want multilb subscribe to both >> repos, and have their packages determined by a yum plugin. > > Amen. It would be nice if we could have them subscribe to the _normal_ > i386 repo -- rather than having a separate repo with just a subset of > packages. The whole crappy 'has a -devel subpackage' heuristic can just > die, but this works _ONLY_ if we fix the tools to do the right thing > when the full set of secondary-arch packages is available. > > For a start, that means fixing yum to refrain from installing both > versions when asked for packages by name. It should install only the > primary arch unless explicitly asked to do otherwise. I think that's the > same as bug #235756 which is filed against the installer. Should it be > moved to yum? > > Secondly, we should kill the dirty hack in RPM which allows packages > with file conflicts in /usr/bin to be installed, with RPM silently > choosing one of the available files. The decision about what to install > should come from whatever's calling RPM; RPM shouldn't be > second-guessing. We should fix our packaging so that these file > conflicts don't exist -- packages with libraries which make sense on the > secondary arch should not also have executables in the same subpackage. > Bug #235757 covers this, as does the subject line of this thread. > > We _might_ get away with just fixing RPM so that it generally does make > the right decision (in particular, installing 32-bit executables on > ppc64 and sparc64). But that's a crappy workaround typical of the kind > of half-arsed crap we've done for multilib in the past; RPM itself is > the wrong place to make such a decision. It lives at a higher level. > However, 'fixing' RPM might be the easiest option before F7, to fix the > perl breakage we've just introduced again -- but it's certainly not the > right answer in the long term. > >> Pros: simple for repo creation >> allows users to customize what they want >> >> Cons: the plugin could take a not-insignificant amount of cpu time/ram to run >> probably would need some core yum changes as well > > I don't understand this plugin. What would it actually do? > > If someone _wants_ something for the secondary arch, they'll install it > manually -- 'yum install firefox.i386', or 'yum install gdb.ppc64'. > >> Basically, there are two reasons that extensive multlib support is/was >> needed: >> >> 1) Runtime - running ppc64 apps on ppc, i386 apps on x86_64 >> >> 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere. >> >> #2 has historically been a problem that multlib solved. In a fully open >> Fedora world, it can be solved with mock (assuming we throw up a full >> ppc64 tree somewhere). > > Multilib hasn't actually solved it very reliably, in a world where so > many people make the mistake of using autoconf. I believe that > pkg-config, in particular, will also always get it wrong. (Bug #224037) > > Mock solves it for packages, and yum's 'installroot' option can do it > for random other builds if necessary. > >> This leaves #1. You could certainly write algorithms to determine 'what >> is a runtime lib' that will operate on any package set and decide what >> to install. But, since any such algorithm will be iterating over the file >> set, it's unlikely to be fast. > > Again I think I'm missing something. We already have algorithms which > handle dependencies on runtime libs. If I 'yum install gdb.ppc64' on a > clean system where I've already done 'yum remove glibc.ppc64' to get rid > of all that unwanted crap in the default install, it knows that it needs > to install ncurses.ppc64 and glibc.ppc64. What do we need that's new? > > The only problem I'm aware of with dependencies is the _manual_ deps, > where a package 'foo-devel' might say that it requires 'bar-devel', but > in fact it should require 'bar-devel.%{ARCH}'. Because otherwise you get > stuff like pango-devel.i386 being satisfied by the existence of > cairo-devel.x86_64. Which doesn't actually work when you come to build > it. Bug #235755. > What can I say, all this sounds like I could have written this myself, so this gets a huge +1 from me. BTW, I think bug 235755 is a dup of a bug of mine (filed against rpm). Regards, Hans From rc040203 at freenet.de Tue Apr 24 13:04:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Apr 2007 15:04:23 +0200 Subject: Spilt libperl from perl In-Reply-To: <462D18D4.5030403@hhs.nl> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> Message-ID: <1177419863.30803.242.camel@mccallum.corsepiu.local> On Mon, 2007-04-23 at 22:36 +0200, Hans de Goede wrote: > Patrice Dumas wrote: > > On Mon, Apr 23, 2007 at 10:21:03PM +0200, Hans de Goede wrote: > >> Actually 2 is a problem that multilib doesn't solve, I've written some > >> scripts / hacks to be able to build i386 on x86_64 without using mock > >> because I have a slow link and thus mock used to take eons, now it only > >> takes ages (--autocache rules!). However these scripts were a big hack, and > >> even with this big hack things didn't always work properly. Using mock is > >> the only sane way to build i386 packages on an x86_64 install. > > > > I am not very knowledgable in those issues, but what about those who > > just want to do a ./configure with the right flags/environemnt vars > > to specifically build an i386 package in an x86_64 install. > > > > That won't work unless you're really really lucky, most configure scripts and > makefiles are not written with this in mind, and thus fail miserably. Multilib support is built into GCC. It will automatically link "the correct libraries" based on the CFLAGS being used to configure. E.g. to be able to build i386 binaries on x86_64, you'd have to have a multilib'ed GCC installed (In RH terms: both gcc.i386 and gcc.x86_64 and all required libraries installed in parallel). Then a configure CFLAGS="-m32" --libdir=/usr/lib should work out of the box. > Also things like pkg-config for example will still look under > /usr/lib64/pkgconfig even when run with/through setarch i386. Right pkg-config is an issue of its own. It lacks multilib support. Ralf From mclasen at redhat.com Tue Apr 24 13:54:14 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 24 Apr 2007 09:54:14 -0400 Subject: Spilt libperl from perl In-Reply-To: <1177419863.30803.242.camel@mccallum.corsepiu.local> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> Message-ID: <1177422855.3616.0.camel@localhost.localdomain> On Tue, 2007-04-24 at 15:04 +0200, Ralf Corsepius wrote: > Right pkg-config is an issue of its own. It lacks multilib support. Because setting PKG_CONFIG_PATH is just too hard, I assume... From rc040203 at freenet.de Tue Apr 24 13:58:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Apr 2007 15:58:20 +0200 Subject: Spilt libperl from perl In-Reply-To: <1177422855.3616.0.camel@localhost.localdomain> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <1177422855.3616.0.camel@localhost.localdomain> Message-ID: <1177423100.30803.277.camel@mccallum.corsepiu.local> On Tue, 2007-04-24 at 09:54 -0400, Matthias Clasen wrote: > On Tue, 2007-04-24 at 15:04 +0200, Ralf Corsepius wrote: > > > Right pkg-config is an issue of its own. It lacks multilib support. > > Because setting PKG_CONFIG_PATH is just too hard, I assume... Nah, pkg-config should take GCC's multilib paths into account ... Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 24 13:58:38 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 24 Apr 2007 15:58:38 +0200 Subject: Fedora buildsys SSL certificate expired? Message-ID: <20070424155838.04688a71@python3.es.egwn.lan> Hi, Running "make build" for ncftp's EL-5 branch, I get a python traceback ending with : OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] make: *** [build] Error 1 I thought it might have been my ~/.fedora.cert file, but nope. Something wrong on the buildsys side or is it just me? 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.39 0.50 0.91 From mclasen at redhat.com Tue Apr 24 14:14:17 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 24 Apr 2007 10:14:17 -0400 Subject: Spilt libperl from perl In-Reply-To: <1177423100.30803.277.camel@mccallum.corsepiu.local> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <1177422855.3616.0.camel@localhost.localdomain> <1177423100.30803.277.camel@mccallum.corsepiu.local> Message-ID: <1177424057.3616.8.camel@localhost.localdomain> On Tue, 2007-04-24 at 15:58 +0200, Ralf Corsepius wrote: > On Tue, 2007-04-24 at 09:54 -0400, Matthias Clasen wrote: > > On Tue, 2007-04-24 at 15:04 +0200, Ralf Corsepius wrote: > > > > > Right pkg-config is an issue of its own. It lacks multilib support. > > > > Because setting PKG_CONFIG_PATH is just too hard, I assume... > > Nah, pkg-config should take GCC's multilib paths into account ... If there was a reasonable api, I might consider a pkgconfig patch. Guessing based on a string returned by uname does not strike me as very maintainable. From mmcgrath at redhat.com Tue Apr 24 14:17:56 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 24 Apr 2007 09:17:56 -0500 Subject: Fedora buildsys SSL certificate expired? In-Reply-To: <20070424155838.04688a71@python3.es.egwn.lan> References: <20070424155838.04688a71@python3.es.egwn.lan> Message-ID: <462E1194.5080200@redhat.com> Matthias Saou wrote: > Hi, > > Running "make build" for ncftp's EL-5 branch, I get a python traceback > ending with : > > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] make: *** [build] Error 1 > > I thought it might have been my ~/.fedora.cert file, but nope. > Something wrong on the buildsys side or is it just me? > > How's does "grep After ~/.fedora.cert" look? -Mike From dcbw at redhat.com Tue Apr 24 14:26:27 2007 From: dcbw at redhat.com (Dan Williams) Date: Tue, 24 Apr 2007 10:26:27 -0400 Subject: Fedora buildsys SSL certificate expired? In-Reply-To: <20070424155838.04688a71@python3.es.egwn.lan> References: <20070424155838.04688a71@python3.es.egwn.lan> Message-ID: <1177424787.13684.6.camel@localhost.localdomain> On Tue, 2007-04-24 at 15:58 +0200, Matthias Saou wrote: > Hi, > > Running "make build" for ncftp's EL-5 branch, I get a python traceback > ending with : > > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] make: *** [build] Error 1 > > I thought it might have been my ~/.fedora.cert file, but nope. > Something wrong on the buildsys side or is it just me? Appears to work for me... but check your cert expiration too. [dcbw at localhost ~]$ plague-client detail 500 Detail for Job ID 500 (superkaramba): -------------------------------------------------------------------------------- Source: superkaramba-0_36-3_fc4 Target: fedora-4-extras Submitter: rdieter at blahblah Status: needsign/ Archjobs: ppc: ppc1.fedora.redhat.com done/done x86_64: hammer2.fedora.redhat.com done/done i386: hammer2.fedora.redhat.com done/done From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 24 14:59:11 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 24 Apr 2007 16:59:11 +0200 Subject: Fedora buildsys SSL certificate expired? In-Reply-To: <462E1194.5080200@redhat.com> References: <20070424155838.04688a71@python3.es.egwn.lan> <462E1194.5080200@redhat.com> Message-ID: <20070424165911.7b71581b@python3.es.egwn.lan> Mike McGrath wrote : > > Running "make build" for ncftp's EL-5 branch, I get a python traceback > > ending with : > > > > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > > handshake failure')] make: *** [build] Error 1 > > > > I thought it might have been my ~/.fedora.cert file, but nope. > > Something wrong on the buildsys side or is it just me? > > > > > > How's does "grep After ~/.fedora.cert" look? Oops, silly me. The new ".fedora.cert" I had downloaded was kept by firefox as ".fedora(2).cert" so I had copied the old one over itself. Working fine now, sorry for the noise. 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.34 0.42 0.44 From Axel.Thimm at ATrpms.net Tue Apr 24 15:17:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Apr 2007 17:17:21 +0200 Subject: Split libperl from perl In-Reply-To: <1177410406.2755.117.camel@pmac.infradead.org> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <1177410406.2755.117.camel@pmac.infradead.org> Message-ID: <20070424151721.GS633@neu.nirvana> On Tue, Apr 24, 2007 at 11:26:46AM +0100, David Woodhouse wrote: > On Mon, 2007-04-23 at 15:55 -0400, Bill Nottingham wrote: > > - Have all repos be single-arch. Those that want multilb subscribe to both > > repos, and have their packages determined by a yum plugin. > > Amen. It would be nice if we could have them subscribe to the _normal_ > i386 repo -- rather than having a separate repo with just a subset of > packages. The whole crappy 'has a -devel subpackage' heuristic can just > die, but this works _ONLY_ if we fix the tools to do the right thing > when the full set of secondary-arch packages is available. > Secondly, we should kill the dirty hack in RPM which allows packages > with file conflicts in /usr/bin to be installed, with RPM silently > choosing one of the available files. The decision about what to install > should come from whatever's calling RPM; RPM shouldn't be > second-guessing. We should fix our packaging so that these file > conflicts don't exist This sounds a lot like asking for bin64 series of the bins with the 64 bit versions taking precedence of the legacy ones (e.g. the typical simplified path gets from /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin to /usr/local/sbin64:/usr/local/sbin:/usr/local/bin64:/usr/local/bin:/sbin64:/sbin:/bin64:/bin:/usr/sbin64:/usr/sbin:/usr/bin64:/usr/bin). I wonder why it was never considered from the start, maybe there is some flaw in this design. Most packages would rebuild properly with a %_(s)bindir defined to /usr/(s)bin64. The ones making some trouble would be the ones that drop off bits into /(s)bin. But their number is managable. As a side effect this would solve the libexec issue as well, but that's just some cosmetics. Note: Of course this solves nothing for 7, but maybe for 8. -- 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:19:38 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 24 Apr 2007 17:19:38 +0200 Subject: Spilt libperl from perl In-Reply-To: <1177419863.30803.242.camel@mccallum.corsepiu.local> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> Message-ID: <20070424151938.GT633@neu.nirvana> On Tue, Apr 24, 2007 at 03:04:23PM +0200, Ralf Corsepius wrote: > > Also things like pkg-config for example will still look under > > /usr/lib64/pkgconfig even when run with/through setarch i386. > Right pkg-config is an issue of its own. It lacks multilib support. Which may be another side-effect fixed by using bin and bin64, e.g. the i386-on-x86_64 developer just removes the 64 bit paths and voila, /usr/bin/pkgconfig does the right thing for i386. And the normal paths take care that /usr/bin64/pkgconfig manages 64 bit libs. Clean separation of archs. -- 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 wtogami at redhat.com Tue Apr 24 16:28:15 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 24 Apr 2007 12:28:15 -0400 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <462DA0EF.80504@redhat.com> References: <462660F6.2070909@redhat.com> <462BFC8A.4090704@redhat.com> <462D057A.30802@redhat.com> <462DA0EF.80504@redhat.com> Message-ID: <462E301F.6000509@redhat.com> Jens Petersen wrote: > >> Sorry, this was considered a Test4 blocker so I have already reverted >> it a few days ago. You might want to check that it was backed out >> properly. > > Yes, I noticed that after sending. I'll update scim later since the > changes should actually be in the system config file not the hardcoded > default. (I was expecting bug reports if the previous version had > stayed in test4 so thanks for sparing me those, though some of them > might have been useful...) But is that particular change to SCIM the right thing to do? I think it is wrong because it creates an inconsistency in configuration. We should instead think about the default hotkey itself first? Warren Togami wtogami at redhat.com From jkeating at redhat.com Tue Apr 24 17:52:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Apr 2007 13:52:30 -0400 Subject: Spilt libperl from perl In-Reply-To: <1177407769.2755.81.camel@pmac.infradead.org> References: <462A6A23.5030409@redhat.com> <200704231917.16147.jkeating@redhat.com> <1177407769.2755.81.camel@pmac.infradead.org> Message-ID: <200704241352.30434.jkeating@redhat.com> On Tuesday 24 April 2007 05:42:49 David Woodhouse wrote: > So we'll get 64-bit /usr/bin/perl, and none of the 32-bit perl modules > (which aren't even _shipped_ 64-bit on ppc) will work. Please don't just > do that. Please apply the _correct_ fix, which is to split the package > so that you can have both versions of libperl, but only the primary > architecture version of the binaries. And this was so much of an issue that you didn't start complaining about this particular case until... a week ago when perl suddenly wasn't multilib again? FC6 has had a multilib perl package since day one. We have so many ppc users that are effected by this that our bugzilla is overwhelmed with... how many bugs? -- 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 dwmw2 at infradead.org Tue Apr 24 18:21:14 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 24 Apr 2007 19:21:14 +0100 Subject: Spilt libperl from perl In-Reply-To: <200704241352.30434.jkeating@redhat.com> References: <462A6A23.5030409@redhat.com> <200704231917.16147.jkeating@redhat.com> <1177407769.2755.81.camel@pmac.infradead.org> <200704241352.30434.jkeating@redhat.com> Message-ID: <1177438874.2755.140.camel@pmac.infradead.org> On Tue, 2007-04-24 at 13:52 -0400, Jesse Keating wrote: > And this was so much of an issue that you didn't start complaining about this > particular case until... a week ago when perl suddenly wasn't multilib again? > FC6 has had a multilib perl package since day one. Yeah... nobody's _ever_ mentioned that we shouldn't be installing all those wrong-arch packages. Ever. I thought there _was_ a bug for it in FC6, actually. I wouldn't swear to it though. Anyway, spot has retracted his claim that splitting the package is a 'dirty hack' and seems inclined to agree that it is in fact the way forward, in accordance with bug #235757. So we are going to go ahead and split perl from libperl after all. -- dwmw2 From buildsys at fedoraproject.org Tue Apr 24 18:53:46 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 24 Apr 2007 14:53:46 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-24 Message-ID: <20070424185346.088AC152131@buildsys.fedoraproject.org> Christian.Iseli AT licr.org: SIBsim4 FE5 > FE7 (0:0.15-1.fc5 > 0:0.14-1.fc7) FE6 > FE7 (0:0.15-1.fc6 > 0:0.14-1.fc7) cbalint AT redhat.com: iverilog FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) gauret AT free.fr: php-adodb FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.4.7-5.fc5 > 0:0.4.6-0.fc6) redhat-bugzilla AT camperquake.de: mcs FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.4.7-5.fc5 > 0:0.4.6-0.fc6) dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) iverilog: cbalint AT redhat.com FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) mcs: redhat-bugzilla AT camperquake.de FE6 > FE7 (0:0.4.1-3.fc6 > 0:0.4.1-2.fc7) php-adodb: gauret AT free.fr FE6 > FE7 (0:4.94-1.fc6 > 0:4.92-1.fc6) SIBsim4: Christian.Iseli AT licr.org FE5 > FE7 (0:0.15-1.fc5 > 0:0.14-1.fc7) FE6 > FE7 (0:0.15-1.fc6 > 0:0.14-1.fc7) From tibbs at math.uh.edu Tue Apr 24 19:49:28 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Apr 2007 14:49:28 -0500 Subject: Summary of the 2007-04-24 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-04-24 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070424 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Minor clarifications to the filename encoding guidelines: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00156.html These should be written into the guidelines soon if this hasn't already been done by the time you read this. Issues pending FESCO ratification: * No proposals are submitted for FESCO consideration this week. Misc business: * Switching the guidelines to recommend the use of %global instead of %define in specfiles. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237448 for a reference. A draft on the differences between %global and %define in specfiles is being prepared and should be presented next week. * FPC's obligations to present information to FESCO and the manner in which that's done. We'll continue to use the current method until FESCO decides they'd like it done differently. - J< From ianburrell at gmail.com Tue Apr 24 20:07:35 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 24 Apr 2007 13:07:35 -0700 Subject: Spilt libperl from perl In-Reply-To: <1177407769.2755.81.camel@pmac.infradead.org> References: <462A6A23.5030409@redhat.com> <200704231554.02102.jkeating@redhat.com> <20070423225053.e4df97d4.bugs.michael@gmx.net> <200704231917.16147.jkeating@redhat.com> <1177407769.2755.81.camel@pmac.infradead.org> Message-ID: On 4/24/07, David Woodhouse wrote: > On Mon, 2007-04-23 at 19:17 -0400, Jesse Keating wrote: > > I don't have a ton of faith in things correctly going from multilib to > > non-multilib and having the obsoletes do the right thing. Given we're at > > test4, I'm going for the least intrusive change, which is to make perl. > > [i386,ppc64] show up in the i386/ppc repos. > > So we'll get 64-bit /usr/bin/perl, and none of the 32-bit perl modules > (which aren't even _shipped_ 64-bit on ppc) will work. Please don't just > do that. Please apply the _correct_ fix, which is to split the package > so that you can have both versions of libperl, but only the primary > architecture version of the binaries. > Did the old way of having multilib perl do that? perl.i386 includes the 32-bit perl modules, in /usr/lib/perl5. perl.x86_64 includes /usr/lib64/perl5 for the 64-bit modules. perl.x86_64 provides the binaries in /usr/bin because it overwrites the 32-bit ones. 32-bit programs that use the libperl.so in /usr/lib will get the 32-bit perl modules. If you split out libperl into a separate package, then everything in /usr/lib/perl5 has to go with it. Otherwise, linking with libperl.so works but it can't run any perl modules. - Ian From ville.skytta at iki.fi Tue Apr 24 21:27:27 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 25 Apr 2007 00:27:27 +0300 Subject: Spilt libperl from perl In-Reply-To: References: <462A6A23.5030409@redhat.com> <1177407769.2755.81.camel@pmac.infradead.org> Message-ID: <200704250027.27508.ville.skytta@iki.fi> On Tuesday 24 April 2007, Ian Burrell wrote: > If you split out libperl into a separate package, then everything in > /usr/lib/perl5 has to go with it. Otherwise, linking with libperl.so > works but it can't run any perl modules. Note that architecture independent perl modules live in /usr/lib/perl5 (on all archs, duh). /usr/share/perl5 would make that more obvious, but that's not something to look into right now. From rc040203 at freenet.de Wed Apr 25 04:49:39 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 25 Apr 2007 06:49:39 +0200 Subject: Spilt libperl from perl In-Reply-To: <20070424151938.GT633@neu.nirvana> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> Message-ID: <1177476579.30803.359.camel@mccallum.corsepiu.local> On Tue, 2007-04-24 at 17:19 +0200, Axel Thimm wrote: > On Tue, Apr 24, 2007 at 03:04:23PM +0200, Ralf Corsepius wrote: > > > Also things like pkg-config for example will still look under > > > /usr/lib64/pkgconfig even when run with/through setarch i386. > > Right pkg-config is an issue of its own. It lacks multilib support. > > Which may be another side-effect fixed by using bin and bin64, Well this would work-around some packaging issues, and some of the issues pkg-config has with building native binaries on multilib'ed systems, but it would not help the actual issue pkgconfig has with multilibs. Consider, GCC uses multilibs at compile-time/link-time. Somewhat oversimplified, multilibs changes GCC's library search paths by appending a relative directory to library-directories (-L). So, if pkgconfig wants to be flexible (multilibs can change over time) and portable (pkg-config is not tied to native compilation, consider cross-compilation), it (a) should check if it is being used with a multilib enabled GCC and (b) if (a) applies, could adopt GCC's multilib library search-path expansion to be able to automatically expand PKG_CONFIG_PATH. > e.g. the i386-on-x86_64 developer just removes the 64 bit paths and > voila, /usr/bin/pkgconfig does the right thing for i386. And the > normal paths take care that /usr/bin64/pkgconfig manages 64 bit libs. The correct API would be to take multilib flags into account: E.g. something similar to pkg-config CC=gcc CFLAGS=-m32 .... on i386/x86_64 platforms or pkg-config CC="avr-gcc" CFLAGS="-mavr5" for an avr cross-compiler targetting avr5 multilibs > Clean separation of archs. This is run-time separation, trying to map link-time separation into run-time separation. This works as long as the number of multilibs is small, but becomes very unhandy, when using pkg-config for systems which have many multilibs (such as many embedded systems). Ralf From Axel.Thimm at ATrpms.net Wed Apr 25 08:52:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 10:52:40 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177476579.30803.359.camel@mccallum.corsepiu.local> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> Message-ID: <20070425085240.GD22427@neu.nirvana> On Wed, Apr 25, 2007 at 06:49:39AM +0200, Ralf Corsepius wrote: > On Tue, 2007-04-24 at 17:19 +0200, Axel Thimm wrote: > > On Tue, Apr 24, 2007 at 03:04:23PM +0200, Ralf Corsepius wrote: > > > > Also things like pkg-config for example will still look under > > > > /usr/lib64/pkgconfig even when run with/through setarch i386. > > > Right pkg-config is an issue of its own. It lacks multilib support. > > > > Which may be another side-effect fixed by using bin and bin64, > Well this would work-around some packaging issues, and some of the > issues pkg-config has with building native binaries on multilib'ed > systems, but it would not help the actual issue pkgconfig has with > multilibs. The idea it to never let the i386 and x86_64 world collide anymore. Different pkgconfigs in different paths (even iof making pkgconfig multilib would be trivial, we want all part of the toolset to become "multilib", so we go a level higher and solve it for all simultaneously). > > Clean separation of archs. > This is run-time separation, trying to map link-time separation into > run-time separation. This works as long as the number of multilibs is > small, but becomes very unhandy, when using pkg-config for systems which > have many multilibs (such as many embedded systems). No, this design includes separation at build-time. The default setup is to use x86_64 bits. Pruning the (s)bin64 parts out of the path you get a pure i386 system (with annoying lib64 folders, see below). So, if the packages never conflict filewise (e.g. separate bin{,64} in addition to the current separate lib{,64} and identical-to-the-mtime /usr/include, /usr/share etc), you get two rather cleanly separated systems. Use case: make_i386() { export SAVEPATH="$PATH" export PATH=`echo $PATH | sed -e's,[^:]*bin64[^:]*,,g' -e's,::*,:,g' -e's,^:,,' -e's,:$,,'` setarch i386 } make_x86_64() { ... } tar -zpxf foo-1.2.3.tar.bz2 ./configure; make make install make distclean make_i386 ./configure; make make install Detection of /usr/lib64 on the pure i386 subsystem will (unfortunately) still be successful (as it is now anyway), but otherwise the whole toolchain will have switched. Give make_i386 and make_x86_64 sensible names and perhaps a better implementation and embed them into /etc/profile.d/*.{c}sh and ready you are. -- 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 dwmw2 at infradead.org Wed Apr 25 08:56:17 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Apr 2007 09:56:17 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425085240.GD22427@neu.nirvana> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> Message-ID: <1177491377.2755.186.camel@pmac.infradead.org> On Wed, 2007-04-25 at 10:52 +0200, Axel Thimm wrote: > The idea it to never let the i386 and x86_64 world collide > anymore. Different pkgconfigs in different paths (even iof making > pkgconfig multilib would be trivial, we want all part of the toolset > to become "multilib", so we go a level higher and solve it for all > simultaneously). I'm sure I've seen packages trying to invoke powerpc-linux-gnu-pkgconfig and powerpc64-linux-gnu-pkgconfig before falling back to just pkgconfig. Can we rely on that? -- dwmw2 From Axel.Thimm at ATrpms.net Wed Apr 25 09:04:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 11:04:50 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177491377.2755.186.camel@pmac.infradead.org> References: <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <1177491377.2755.186.camel@pmac.infradead.org> Message-ID: <20070425090450.GE22427@neu.nirvana> On Wed, Apr 25, 2007 at 09:56:17AM +0100, David Woodhouse wrote: > On Wed, 2007-04-25 at 10:52 +0200, Axel Thimm wrote: > > The idea it to never let the i386 and x86_64 world collide > > anymore. Different pkgconfigs in different paths (even iof making > > pkgconfig multilib would be trivial, we want all part of the toolset > > to become "multilib", so we go a level higher and solve it for all > > simultaneously). > > I'm sure I've seen packages trying to invoke powerpc-linux-gnu-pkgconfig > and powerpc64-linux-gnu-pkgconfig before falling back to just pkgconfig. Yes, most autoconf projects check for toolsets with the triple prefixed before testing the actual "pure" names. Same goes for gcc or binutils components. > Can we rely on that? Only if you assume all projects use autoconf and use autoconf's defaults. E.g. no, we can't. :/ But in the bin/bin64 scenario these projects would find the correct tool just by the set path. As noted the only black spot is that some projects testing for /usr/lib64 before testing for /usr/lib (which is the usual case to find out whether this is x86_64 or i386) will try to build with -L/usr/lib64 and to install under $DESTDIR/usr/lib64, but that cannot be avoided in any multilib scheme (other than hackery tricks like LD_PRELOADing a lib that would make stat to these folders fail). For building these projects one will have to resort to the same trick we use in specfiles, e.g. to not let the project detect libdir itself, but to force it to use the proper one. But that's a problem now anyway, just mentioning what the suggested bin64 proposal will not be able to fix. -- 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 Wed Apr 25 10:50:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 25 Apr 2007 12:50:14 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177491377.2755.186.camel@pmac.infradead.org> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <1177491377.2755.186.camel@pmac.infradead.org> Message-ID: <1177498214.30803.429.camel@mccallum.corsepiu.local> On Wed, 2007-04-25 at 09:56 +0100, David Woodhouse wrote: > On Wed, 2007-04-25 at 10:52 +0200, Axel Thimm wrote: > > The idea it to never let the i386 and x86_64 world collide > > anymore. Different pkgconfigs in different paths (even iof making > > pkgconfig multilib would be trivial, we want all part of the toolset > > to become "multilib", so we go a level higher and solve it for all > > simultaneously). > > I'm sure I've seen packages trying to invoke powerpc-linux-gnu-pkgconfig > and powerpc64-linux-gnu-pkgconfig before falling back to just pkgconfig. > > Can we rely on that? Nope, 1. This is "per-arch canonicalisation". It is not related to multilibs at all. In general, multilibs exist "below/within one arch" forming hierarchies of "compatible libs", not "next/neighboring". It's just a random coincidence/peculiarity/special case that i386 and x86_64 are "neighboring". 2. Last time I tried this approach, there were other bugs in pkg-config preventing this from being functional. I'd have to check if this still applies. Also, the per-arch wrapper approach (write a script wrapper around /usr/bin/pkg-config to process options is unreliable because pkg-config doesn't process args correctly. Ralf From bugs.michael at gmx.net Wed Apr 25 11:07:09 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Apr 2007 13:07:09 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425085240.GD22427@neu.nirvana> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> Message-ID: <20070425130709.ba871bde.bugs.michael@gmx.net> On Wed, 25 Apr 2007 10:52:40 +0200, Axel Thimm wrote: > So, if the packages never conflict filewise (e.g. separate bin{,64} in > addition to the current separate lib{,64} and identical-to-the-mtime > /usr/include, /usr/share etc), you get two rather cleanly separated > systems. And "identical-to-the-mtime /usr/include" are a roadblock. Many of the headers are created at build-time and contain build-target-specific definitions. From rc040203 at freenet.de Wed Apr 25 11:15:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 25 Apr 2007 13:15:07 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425090450.GE22427@neu.nirvana> References: <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <1177491377.2755.186.camel@pmac.infradead.org> <20070425090450.GE22427@neu.nirvana> Message-ID: <1177499707.30803.439.camel@mccallum.corsepiu.local> On Wed, 2007-04-25 at 11:04 +0200, Axel Thimm wrote: > On Wed, Apr 25, 2007 at 09:56:17AM +0100, David Woodhouse wrote: > > On Wed, 2007-04-25 at 10:52 +0200, Axel Thimm wrote: > > > The idea it to never let the i386 and x86_64 world collide > > > anymore. Different pkgconfigs in different paths (even iof making > > > pkgconfig multilib would be trivial, we want all part of the toolset > > > to become "multilib", so we go a level higher and solve it for all > > > simultaneously). > > > > I'm sure I've seen packages trying to invoke powerpc-linux-gnu-pkgconfig > > and powerpc64-linux-gnu-pkgconfig before falling back to just pkgconfig. > > Yes, most autoconf projects check for toolsets with the triple > prefixed before testing the actual "pure" names. Same goes for gcc or > binutils components. AC_CHECK_TOOL/AC_PATH_TOOL is what you are looking for. > > Can we rely on that? > > Only if you assume all projects use autoconf and use autoconf's > defaults. E.g. no, we can't. :/ As I already wrote, this only helps "per-target" prefixed toolchains. It doesn't help multilibs. > But in the bin/bin64 scenario these projects would find the correct > tool just by the set path. > > As noted the only black spot is that some projects testing for > /usr/lib64 before testing for /usr/lib (which is the usual case to > find out whether this is x86_64 or i386) will try to build with > -L/usr/lib64 and to install under $DESTDIR/usr/lib64, but that cannot > be avoided in any multilib scheme (other than hackery tricks like > LD_PRELOADing a lib that would make stat to these folders fail). > > For building these projects one will have to resort to the same trick > we use in specfiles, e.g. to not let the project detect libdir itself, > but to force it to use the proper one. > > But that's a problem now anyway, just mentioning what the suggested > bin64 proposal will not be able to fix. Yes, it doesn't help, because wrt. pkg-config the culprit is in pkg-config. [BTW: Libtool has the same issue. RH has been (is?) shipping a hacked libtool which automatically switches to lib64 with -m64 and to lib with -m32, but ... this approach also lacks generality and actually doesn't help the general case] Ralf From jakub at redhat.com Wed Apr 25 11:16:20 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 25 Apr 2007 07:16:20 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425085240.GD22427@neu.nirvana> References: <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> Message-ID: <20070425111620.GD355@devserv.devel.redhat.com> On Wed, Apr 25, 2007 at 10:52:40AM +0200, Axel Thimm wrote: > The default setup is to use x86_64 bits. Pruning the (s)bin64 parts > out of the path you get a pure i386 system (with annoying lib64 > folders, see below). {,s}bin64 is a terribly bad idea. For almost all binaries (very few exceptions) users don't really care whether they are running 64-bit or 32-bit binary, it should have exactly the same functionality. So having both /bin/ls and /bin64/ls serves no useful purpose (in addition to violating FHS). The exceptions are: 1) programs where the 64-bit version can handle 32-bit and 64-bit stuff, but the 32-bit one can't (on i386/x86_64 this is e.g. gcc (but on say ppc/ppc64 not), gdb, strace, and a few others) - this is best solved by just telling the package management about it - some "prefer 64-bit flag" 2) programs that use plugins which aren't for whatever reason available for both wordsizes - firefox, perhaps perl, python. For firefox this is easily solvable, as /usr/bin/firefox is just a shell wrapper script, it wouldn't be hard to add --prefer32 and --prefer64 options to it to tweak the hardcoded preference. For python/perl it can very well be handled by also shipping the binary in /usr/lib{,64}/{python,perl}*/{python,perl} or something, you don't need to create bin64 dirs for this I believe there is no reason to kill rpm's multilib handling, as long as it is configurable which arch is preferred (so that we don't prefer say ppc64 on ppc where 32-bit code is generally faster) and as long as there is some way for packages to override this (a "prefer {32,64}-bit flag"). For an average library package which contains a bunch of big libraries and a couple of small binaries and/or data files in addition to that rpm's multilib can be used just fine. But there should be a policy that when the binaries and/or data files occupy a big part of the package the libraries should be split into a subpackage, to e.g. limit the download sizes. If we through some tag annotate all packages ("this package should be only installed for the primary arch", "this package can be installed for both arches if needed (usually library package)", "this package should only be installed for one arch, preferrably XYZ"), then yum etc. can make smart decisions fairly cheaply and we can also use the separate arch repositories easily. Jakub From dwmw2 at infradead.org Wed Apr 25 13:31:41 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Apr 2007 14:31:41 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425130709.ba871bde.bugs.michael@gmx.net> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425130709.ba871bde.bugs.michael@gmx.net> Message-ID: <1177507901.2755.218.camel@pmac.infradead.org> On Wed, 2007-04-25 at 13:07 +0200, Michael Schwendt wrote: > And "identical-to-the-mtime /usr/include" are a roadblock. Many of the > headers are created at build-time and contain build-target-specific > definitions. The 'identical-to-the-mtime' criterion was a serious error of judgement from the very beginning, and can be fixed. If the file contents are identical, the file is identical. -- dwmw2 From wtogami at redhat.com Wed Apr 25 13:42:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 25 Apr 2007 09:42:01 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070425085240.GD22427@neu.nirvana> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> Message-ID: <462F5AA9.2030300@redhat.com> If we are considering such a fundamental change like this, why not instead go for fat binaries? Warren Togami wtogami at redhat.com From dwmw2 at infradead.org Wed Apr 25 13:46:12 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Apr 2007 14:46:12 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425111620.GD355@devserv.devel.redhat.com> References: <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> Message-ID: <1177508772.2755.231.camel@pmac.infradead.org> On Wed, 2007-04-25 at 07:16 -0400, Jakub Jelinek wrote: > I believe there is no reason to kill rpm's multilib handling, as long as > it is configurable which arch is preferred (so that we don't prefer > say ppc64 on ppc where 32-bit code is generally faster) and as long as > there is some way for packages to override this (a "prefer {32,64}-bit > flag"). I've hacked up something like this as a test -- I've made RPM's preference of 32-bit vs 64-bit be configurable. http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch I'm doing an install with anaconda modified to set %_prefer_color to 1 on ppc64, so that we prefer 32-bit. I expect it to work fine except for /sbin/ldconfig, which is about the only case where we _do_ want 64-bit. (I don't include gdb in the above statement because there's no need for the 32-bit gdb to be installed and to force RPM to choose; while there _is_ a need for both versions of glibc, which is what provides /sbin/ldconfig.) Of course, if /sbin/ldconfig wasn't in the same package as the libc libraries, and we could install _just_ the 64-bit version of the package which contains ldconfig, it would be fine. We could perhaps contrive ways to indicate to RPM that we want a certain flavour of binary to be preferred when both are installed simultanously -- but I can't see any way to do it which isn't going to be ugly, and really it's none of RPM's business -- it's the job of yum or the user, or whatever/whoever _calls_ RPM to make decisions about what should be installed. I think it's much better to have a packaging policy which forbids the file conflicts -- letting RPM deal with them by second-guessing was only ever a dirty hack. > If we through some tag annotate all packages ("this package should be > only installed for the primary arch", "this package can be installed for > both arches if needed (usually library package)", "this package should > only be installed for one arch, preferrably XYZ"), then yum etc. can > make smart decisions fairly cheaply and we can also use the separate > arch repositories easily. That makes some sense, but it's for _yum_, as you say. Not for RPM (where it might have to be per-file anyway). -- dwmw2 From dwmw2 at infradead.org Wed Apr 25 13:46:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Apr 2007 14:46:43 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <462F5AA9.2030300@redhat.com> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <462F5AA9.2030300@redhat.com> Message-ID: <1177508803.2755.233.camel@pmac.infradead.org> On Wed, 2007-04-25 at 09:42 -0400, Warren Togami wrote: > If we are considering such a fundamental change like this, why not > instead go for fat binaries? That's not the first time I've heard this. Can you explain in detail how it would work and how it would actually address the problems? -- dwmw2 From dwmw2 at infradead.org Wed Apr 25 14:01:00 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Apr 2007 15:01:00 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177508772.2755.231.camel@pmac.infradead.org> References: <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <1177508772.2755.231.camel@pmac.infradead.org> Message-ID: <1177509660.2755.241.camel@pmac.infradead.org> On Wed, 2007-04-25 at 14:46 +0100, David Woodhouse wrote: > I've hacked up something like this as a test -- I've made RPM's > preference of 32-bit vs 64-bit be configurable. > http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch > > I'm doing an install with anaconda modified to set %_prefer_color to 1 > on ppc64, so that we prefer 32-bit. I expect it to work fine except > for /sbin/ldconfig, which is about the only case where we _do_ want > 64-bit. The install seems fine. The 32-bit ldconfig seems perfectly capable of making symlinks in /usr/lib64, and 64-bit binaries work fine. I wasn't expecting to have 64-bit binaries apart from gdb, which I installed manually -- but I'd forgotten about bug 233427, in which yum gets the preference wrong and selects the 64-bit version of the package instead of the 32-bit for some packages. -- dwmw2 From jakub at redhat.com Wed Apr 25 14:03:43 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 25 Apr 2007 10:03:43 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177508772.2755.231.camel@pmac.infradead.org> References: <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <1177508772.2755.231.camel@pmac.infradead.org> Message-ID: <20070425140343.GG355@devserv.devel.redhat.com> On Wed, Apr 25, 2007 at 02:46:12PM +0100, David Woodhouse wrote: > I'm doing an install with anaconda modified to set %_prefer_color to 1 > on ppc64, so that we prefer 32-bit. I expect it to work fine except > for /sbin/ldconfig, which is about the only case where we _do_ want > 64-bit. /sbin/ldconfig doesn't care, 32-bit ldconfig on ppc can handle 64-bit libraries and vice versa, even on i?86 32-bit ldconfig it can handle x86_64 and ia64. > We could perhaps contrive ways to indicate to RPM that we want a certain > flavour of binary to be preferred when both are installed simultanously > -- but I can't see any way to do it which isn't going to be ugly, and > really it's none of RPM's business -- it's the job of yum or the user, > or whatever/whoever _calls_ RPM to make decisions about what should be > installed. But RPM packages can contain hints for yum and other utilities on top of rpm. IMHO that's better than keeping the info in some on the side metadata. Jakub From dwmw2 at infradead.org Wed Apr 25 14:12:07 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Apr 2007 15:12:07 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425140343.GG355@devserv.devel.redhat.com> References: <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <1177508772.2755.231.camel@pmac.infradead.org> <20070425140343.GG355@devserv.devel.redhat.com> Message-ID: <1177510327.2755.248.camel@pmac.infradead.org> On Wed, 2007-04-25 at 10:03 -0400, Jakub Jelinek wrote: > On Wed, Apr 25, 2007 at 02:46:12PM +0100, David Woodhouse wrote: > > I'm doing an install with anaconda modified to set %_prefer_color to 1 > > on ppc64, so that we prefer 32-bit. I expect it to work fine except > > for /sbin/ldconfig, which is about the only case where we _do_ want > > 64-bit. > > /sbin/ldconfig doesn't care, 32-bit ldconfig on ppc can handle 64-bit > libraries and vice versa, even on i?86 32-bit ldconfig it can handle x86_64 and > ia64. Ah, OK. So preferring 32-bit binaries on ppc64 and sparc64 does seem like the right thing to do. I can't think of any case where it's wrong (cases where you actually want _both_ packages installed, at least). It'd certainly bring the ppc64 and x86_64 multilib closer together, because then RPM would be choosing the the primary architecture by default on both of them, instead of choosing the secondary arch. > > We could perhaps contrive ways to indicate to RPM that we want a certain > > flavour of binary to be preferred when both are installed simultanously > > -- but I can't see any way to do it which isn't going to be ugly, and > > really it's none of RPM's business -- it's the job of yum or the user, > > or whatever/whoever _calls_ RPM to make decisions about what should be > > installed. > > But RPM packages can contain hints for yum and other utilities on top of > rpm. IMHO that's better than keeping the info in some on the side metadata. Well, I suppose we don't _need_ that hint in RPM about specific files. The only example I could think of was ldconfig and I was wrong about it. So perhaps we could get away with keeping the dirty hack in RPM to choose files, fixing the default on ppc64 and sparc64 to be 32-bit, and just making sure we split those packages where the user might _choose_ to have a 64-bit version instead of a 32-bit version for some reason. I don't like that much -- I'd rather get rid of the hack in RPM and get rid of all the conflicts. But it's technically feasible, I suppose. -- dwmw2 From nicolas.mailhot at laposte.net Wed Apr 25 14:28:55 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 25 Apr 2007 16:28:55 +0200 (CEST) Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <462F5AA9.2030300@redhat.com> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <462F5AA9.2030300@redhat.com> Message-ID: <42240.192.54.193.51.1177511335.squirrel@rousalka.dyndns.org> Le Mer 25 avril 2007 15:42, Warren Togami a ?crit : > If we are considering such a fundamental change like this, why not > instead go for fat binaries? Forcing everyone to keep a 32 bit env? (some people strip %doc now) Rewriting all the makefiles to generate fat binaries (instead of just moving a few files)? -- Nicolas Mailhot From buc at odusz.so-cdu.ru Wed Apr 25 15:16:15 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 25 Apr 2007 19:16:15 +0400 Subject: Orphaned package: pam_usb Message-ID: <462F70BF.4050806@odu.neva.ru> I am not interested in this package now, feel free to get it. BTW, a new version 0.4.0 is available at http://www.pamusb.org . Regards, Dmitry Butskoy From laroche at redhat.com Wed Apr 25 15:28:58 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 25 Apr 2007 17:28:58 +0200 Subject: uulib-devel, beryl-dbus Message-ID: <20070425152858.GA13428@dudweiler.stuttgart.redhat.com> Seems uulib-devel is still pushed out to the FE-extras directory. Shouldn't this be blocked as also the main lib is not pushed out at all? Also beryl-dbus is still in FE-development, but is already obsoleted. regards, Florian La Roche From bugs.michael at gmx.net Wed Apr 25 15:45:40 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 25 Apr 2007 17:45:40 +0200 Subject: uulib-devel, beryl-dbus In-Reply-To: <20070425152858.GA13428@dudweiler.stuttgart.redhat.com> References: <20070425152858.GA13428@dudweiler.stuttgart.redhat.com> Message-ID: <20070425174540.46f24580.bugs.michael@gmx.net> On Wed, 25 Apr 2007 17:28:58 +0200, Florian La Roche wrote: > Seems uulib-devel is still pushed out to the > FE-extras directory. Shouldn't this be blocked > as also the main lib is not pushed out at all? There is no main lib. It's a static-only uulib-devel package and uudeview package built from uudeview src rpm. > Also beryl-dbus is still in FE-development, but > is already obsoleted. There has not been any removal request, and we don't have any tool yet to evaluate the "dead.package" files. It will be gone with the next push. From laroche at redhat.com Wed Apr 25 15:51:01 2007 From: laroche at redhat.com (Florian La Roche) Date: Wed, 25 Apr 2007 17:51:01 +0200 Subject: uulib-devel, beryl-dbus In-Reply-To: <20070425174540.46f24580.bugs.michael@gmx.net> References: <20070425152858.GA13428@dudweiler.stuttgart.redhat.com> <20070425174540.46f24580.bugs.michael@gmx.net> Message-ID: <20070425155101.GA14388@dudweiler.stuttgart.redhat.com> On Wed, Apr 25, 2007 at 05:45:40PM +0200, Michael Schwendt wrote: > On Wed, 25 Apr 2007 17:28:58 +0200, Florian La Roche wrote: > > > Seems uulib-devel is still pushed out to the > > FE-extras directory. Shouldn't this be blocked > > as also the main lib is not pushed out at all? > > There is no main lib. It's a static-only uulib-devel package and uudeview > package built from uudeview src rpm. Ok, I've filed the ollowing bugzilla about this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237836 [laroche at porky i386]$ rpm -qp --provides uulib-devel-0.5.20-11.i386.rpm uulib = {version}-11 uulib-devel = 0.5.20-11 [laroche at porky i386]$ > > > Also beryl-dbus is still in FE-development, but > > is already obsoleted. > > There has not been any removal request, and we don't have any > tool yet to evaluate the "dead.package" files. Should probably just be added to the "broken dep" report that is sent out. > > It will be gone with the next push. Thanks a lot. regards, Florian La Roche From jdieter at gmail.com Wed Apr 25 15:53:25 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 25 Apr 2007 18:53:25 +0300 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <42240.192.54.193.51.1177511335.squirrel@rousalka.dyndns.org> References: <1177357164.5956.23.camel@localhost.localdomain> <20070423194541.GA16904@nostromo.devel.redhat.com> <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <462F5AA9.2030300@redhat.com> <42240.192.54.193.51.1177511335.squirrel@rousalka.dyndns.org> Message-ID: <1177516405.3944.23.camel@jndwidescreen.lesbg.loc> Just a thought as I've been following this thread. I've been working on getting yum-presto to work on my wife's x86_64 system, and the whole multi-lib problem really comes into focus. Evolution, gtk2, gtk2-devel and numerous other packages have both x86_64 and i386 versions installed on her system. When trying to use yum-presto to update these packages, rebuilding the rpm from the deltarpm will fail for i386 because rpm only installs /usr/bin/* from the x86_64 package (which is what it's supposed to do). That means I end up downloading one deltarpm and one full rpm for these packages rather than two deltarpms. All that to say that if we're not too worried about deltarpms and F8, it's not really a problem, but if we are wanting to use it, we really need to work away from using file-colors in rpm. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Wed Apr 25 16:52:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 18:52:21 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425111620.GD355@devserv.devel.redhat.com> References: <462D0E38.8090904@redhat.com> <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> Message-ID: <20070425165221.GO11831@neu.nirvana> On Wed, Apr 25, 2007 at 07:16:20AM -0400, Jakub Jelinek wrote: > On Wed, Apr 25, 2007 at 10:52:40AM +0200, Axel Thimm wrote: > > The default setup is to use x86_64 bits. Pruning the (s)bin64 parts > > out of the path you get a pure i386 system (with annoying lib64 > > folders, see below). > > {,s}bin64 is a terribly bad idea. For almost all binaries (very few > exceptions) users don't really care whether they are running 64-bit > or 32-bit binary, it should have exactly the same functionality. You could argue that the only reason multilib exists at all is that one arch has some benefits over the other, like the one having a better performance of the hardware resources, but the other carrying more packages (especially from ISVs these days). This is the typical i386/x86_64 dilemma. > So having both /bin/ls and /bin64/ls serves no useful purpose Consider (*) yum install foo.i386 yum install foo.x86_64 yum remove foo.x86_64 rpm -V foo (same for smart and apt) The current multilib model in rpm with blindly overwriting files is broken by design (e.g. unfixable in shared bindir environments). You cannot consider the packaging system a stateless machine anymore. Adding to the design issues there are also implementation bugs with %docs and %langs that get uninstalled when the i386 package gets uninstalled and so on. Furthermore foo.i386 and foo.x86_64 packages often alread conflict on other files which is silently muted during coinstallation. It is getting so much convoluted with rpm, yum and anaconda exceptions and bug workarounds that we need a clean model. And packaging wise this means no more overwriting of files with foreign contents. > (in addition to violating FHS). Yes, that's severe, but due to multilib we were forced to break the FHS (libexec) anyway, and currently the FHS is adjourning again and we could bring that in. I already submitted a request to consider adding libexec to the next FHS, but if we were to go bin64, we don't even need it anymore and I could instead promote for bin64. > I believe there is no reason to kill rpm's multilib handling, as > long as it is configurable which arch is preferred Well, if all rpm multilib bugs are fixed, whereas fixing (*) above is impossible, that could sound OK, but we have these bugs in rpm for years, from the very first day of multilib in rpm, and nothing is happening. This is not an offence against Paul & friends, who're doing their best at fighting the rpm monster, it is just that rpm's code is still that unmaintainable and perhaps we need to lift off some mechanisms to lower end mechanics. Like for example solving the multilib issue w/o the aid of the packaging system, so that the packaging system gets back to where it belonged, maintaining single packages and their dependencies. > If we through some tag annotate all packages ("this package should be > only installed for the primary arch", "this package can be installed for > both arches if needed (usually library package)", "this package should > only be installed for one arch, preferrably XYZ"), then yum etc. can > make smart decisions fairly cheaply and we can also use the separate > arch repositories easily. You're advocating the opposite, e.g. let higher level tools solve the issue. But if the lower levels fail (like install/remove a package not being a zero-op, or buggy behaviour nuking %doc/%lang), then yum and anaconda will fail, too. Therefore we should really examine the solutions at the low end scale and bin64 would be such a solution that is functionally at least equivalent to the current situation while "fixing" in one sweep all rpm multilib bugs (by not having to use any rpm-multilib features). -- 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 Wed Apr 25 16:55:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 18:55:17 +0200 Subject: Where is rpm.org development discussed? Message-ID: <20070425165517.GP11831@neu.nirvana> Hi, rpm.org hosts lists for rpm maintainers, e.g. the rpm packagers of various vendors. The old rpm-devel lists seems to be dedicated to rpm development of the jbj codebase, at least that's what I'm being told where I raise Fedora/RHEL issues there. And the rpm gods there are less than cooperative. So do we need a new rpm.org rpm-devel list? -- 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 ajackson at redhat.com Wed Apr 25 16:47:33 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 25 Apr 2007 12:47:33 -0400 Subject: Where is rpm.org development discussed? In-Reply-To: <20070425165517.GP11831@neu.nirvana> References: <20070425165517.GP11831@neu.nirvana> Message-ID: <1177519653.2745.3.camel@localhost.localdomain> On Wed, 2007-04-25 at 18:55 +0200, Axel Thimm wrote: > Hi, > > rpm.org hosts lists for rpm maintainers, e.g. the rpm packagers of > various vendors. The old rpm-devel lists seems to be dedicated to rpm > development of the jbj codebase, at least that's what I'm being told > where I raise Fedora/RHEL issues there. And the rpm gods there are > less than cooperative. > > So do we need a new rpm.org rpm-devel list? I'm reasonably sure rpm-maint at lists.rpm.org is supposed to be that list. - ajax From pertusus at free.fr Wed Apr 25 17:09:32 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 25 Apr 2007 19:09:32 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425165221.GO11831@neu.nirvana> References: <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> Message-ID: <20070425170932.GA2995@free.fr> On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote: > Consider (*) > > yum install foo.i386 > yum install foo.x86_64 > yum remove foo.x86_64 > rpm -V foo > (same for smart and apt) > > The current multilib model in rpm with blindly overwriting files is > broken by design (e.g. unfixable in shared bindir environments). You > cannot consider the packaging system a stateless machine anymore. Another way of avoiding this issue, however, would be to have normal conflicts in (/usr)/(s)bin. All the multilib enabled packages would have to do subpackages without conflicting files and only those subpackaged could be multilib parallel installable. This is another way to solve the issue. It might involve wrapper scripts for executable we really want to be parallel installable, this issue is indeed better solved with different (/usr)/(s)bin, but I guess that the number of executables we want to have in paralell is not a lot. > Adding to the design issues there are also implementation bugs with > %docs and %langs that get uninstalled when the i386 package gets > uninstalled and so on. That looks like a bug, not a real issue. > Furthermore foo.i386 and foo.x86_64 packages > often alread conflict on other files which is silently muted during > coinstallation. How is it possible? > It is getting so much convoluted with rpm, yum and anaconda exceptions > and bug workarounds that we need a clean model. And packaging wise > this means no more overwriting of files with foreign contents. Except if they have the same md5 sum? -- Pat From Axel.Thimm at ATrpms.net Wed Apr 25 17:39:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 25 Apr 2007 19:39:42 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425170932.GA2995@free.fr> References: <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> Message-ID: <20070425173942.GU11831@neu.nirvana> On Wed, Apr 25, 2007 at 07:09:32PM +0200, Patrice Dumas wrote: > On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote: > > Consider (*) > > > > yum install foo.i386 > > yum install foo.x86_64 > > yum remove foo.x86_64 > > rpm -V foo > > (same for smart and apt) > > > > The current multilib model in rpm with blindly overwriting files is > > broken by design (e.g. unfixable in shared bindir environments). You > > cannot consider the packaging system a stateless machine anymore. > > Another way of avoiding this issue, however, would be to have > normal conflicts in (/usr)/(s)bin. All the multilib enabled packages > would have to do subpackages without conflicting files and only those > subpackaged could be multilib parallel installable. This is another way > to solve the issue. Yes, but it does involve much more work to do. And if we assume that every package is in principle candidate for multilib, we would end with a guidelines to have all packages using bindir to split off subpackages. The setting _bindir=/usr/bin64 would already fix the majority of packages w/o having to touhc the specfile. > It might involve wrapper scripts for executable we really want to be > parallel installable, this issue is indeed better solved with > different (/usr)/(s)bin, but I guess that the number of executables > we want to have in paralell is not a lot. In theory everything. The idea is to not even have to choose what is worth multilibbing or not. That's the paths we've taken until now and that is causing so much administrative overhead. > > Adding to the design issues there are also implementation bugs with > > %docs and %langs that get uninstalled when the i386 package gets > > uninstalled and so on. > > That looks like a bug, not a real issue. The real issue is that these bugs get never fixed. > > Furthermore foo.i386 and foo.x86_64 packages > > often alread conflict on other files which is silently muted during > > coinstallation. > > How is it possible? you mean how does rpm do that, or how do the packages and up having conflicting contents? I just did an RHEL5 full install (we're talking Fedora, but for now I only have these numbers fresh to quote, FC6 will be similar): Momentarily after installing the system I did an rpm -Va and examined the output: It was either 53 or 58 packages that were not verifying due to multilib problems. Just as an example: # rpm -V samba-common .......T /etc/rc.d/init.d/winbind .......T c /etc/samba/lmhosts .......T c /etc/samba/smb.conf .......T /usr/include/libmsrpc.h .......T /usr/include/libsmbclient.h .......T d /usr/share/man/man1/ntlm_auth.1.gz .......T d /usr/share/man/man1/profiles.1.gz .......T d /usr/share/man/man1/smbcquotas.1.gz .......T d /usr/share/man/man1/testparm.1.gz .......T d /usr/share/man/man1/vfstest.1.gz .......T d /usr/share/man/man1/wbinfo.1.gz .......T d /usr/share/man/man5/lmhosts.5.gz .......T d /usr/share/man/man5/smb.conf.5.gz .......T d /usr/share/man/man7/libsmbclient.7.gz .......T d /usr/share/man/man7/pam_winbind.7.gz .......T d /usr/share/man/man8/net.8.gz .......T d /usr/share/man/man8/smbpasswd.8.gz .......T d /usr/share/man/man8/winbindd.8.gz ......G. /var/cache/samba/winbindd_privileged ......G. /var/cache/samba/winbindd_privileged > > It is getting so much convoluted with rpm, yum and anaconda exceptions > > and bug workarounds that we need a clean model. And packaging wise > > this means no more overwriting of files with foreign contents. > > Except if they have the same md5 sum? Yes and no. One can discuss the usefulness of mtime verification (I personally think it is useful, and I think the packages can be made to have the same timestamps on both archs, just use install -p and for generated files use touch -r from the master files), but there is far more important metadata like owner/group and mode of the files that should never be ignored and allowed to conflict. -- 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 dominik at greysector.net Wed Apr 25 17:45:36 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 25 Apr 2007 19:45:36 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425173942.GU11831@neu.nirvana> References: <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> Message-ID: <20070425174535.GB12287@ryvius.pekin.waw.pl> On Wednesday, 25 April 2007 at 19:39, Axel Thimm wrote: > On Wed, Apr 25, 2007 at 07:09:32PM +0200, Patrice Dumas wrote: > > On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote: > > > Consider (*) > > > > > > yum install foo.i386 > > > yum install foo.x86_64 > > > yum remove foo.x86_64 > > > rpm -V foo > > > (same for smart and apt) > > > > > > The current multilib model in rpm with blindly overwriting files is > > > broken by design (e.g. unfixable in shared bindir environments). You > > > cannot consider the packaging system a stateless machine anymore. > > > > Another way of avoiding this issue, however, would be to have > > normal conflicts in (/usr)/(s)bin. All the multilib enabled packages > > would have to do subpackages without conflicting files and only those > > subpackaged could be multilib parallel installable. This is another way > > to solve the issue. > > Yes, but it does involve much more work to do. It is something worth doing IMHO. > And if we assume that > every package is in principle candidate for multilib, we would end > with a guidelines to have all packages using bindir to split off > subpackages. The setting _bindir=/usr/bin64 would already fix the > majority of packages w/o having to touhc the specfile. I don't think we should be considering {,s}bin64 abomination. It'd create too much confusion among the userbase. See Jakub's post. [...] > > > Furthermore foo.i386 and foo.x86_64 packages > > > often alread conflict on other files which is silently muted during > > > coinstallation. > > > > How is it possible? > > you mean how does rpm do that, or how do the packages and up having > conflicting contents? > > I just did an RHEL5 full install (we're talking Fedora, but for now I > only have these numbers fresh to quote, FC6 will be similar): > Momentarily after installing the system I did an rpm -Va and examined > the output: It was either 53 or 58 packages that were not verifying > due to multilib problems. > > Just as an example: > # rpm -V samba-common > .......T /etc/rc.d/init.d/winbind > .......T c /etc/samba/lmhosts > .......T c /etc/samba/smb.conf > .......T /usr/include/libmsrpc.h > .......T /usr/include/libsmbclient.h Those should be in a -devel package and libs should be split off, too. Clearly a packaging bug. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rdieter at math.unl.edu Wed Apr 25 17:47:29 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 25 Apr 2007 12:47:29 -0500 Subject: exiv2-0.14 abi and (slight) api change Message-ID: <462F9431.4040300@math.unl.edu> FYI, I've updated f7/devel to exiv2-0.14 this morning, which includes an abi and (slight) api change. I've already been in contact with the maintainers of dependent packages: * digikam * gwenview * kphotoalbum (me) * libkexiv2 (me) and queued patched builds. * ufraw (see http://bugzilla.redhat.com/237846) We'll likely push these updates to FC-6 (and possibly FC-5) soon, given these builds prove themselves field-test-worthy. -- Rex From dwmw2 at infradead.org Wed Apr 25 21:03:00 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 25 Apr 2007 22:03:00 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425174535.GB12287@ryvius.pekin.waw.pl> References: <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> Message-ID: <1177534980.2755.265.camel@pmac.infradead.org> On Wed, 2007-04-25 at 19:45 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > Another way of avoiding this issue, however, would be to have > > > normal conflicts in (/usr)/(s)bin. All the multilib enabled packages > > > would have to do subpackages without conflicting files and only those > > > subpackaged could be multilib parallel installable. This is another way > > > to solve the issue. You're talking about bug #235757, which is just one dependency of the multilib tracker bug: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=multilib > > Yes, but it does involve much more work to do. Packaging is hard. Let's go shopping. > It is something worth doing IMHO. Absolutely. > > And if we assume that > > every package is in principle candidate for multilib, we would end > > with a guidelines to have all packages using bindir to split off > > subpackages. The setting _bindir=/usr/bin64 would already fix the > > majority of packages w/o having to touhc the specfile. Yep. That seems to be the best, cleanest, fix. It helps a little bit if we fix RPM to actually make the _right_ decision when it's forced to choose between conflicting files (http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch), but really, RPM shouldn't be making those decisions. It should just be installing what it's told to, and it shouldn't be told to install stuff which conflicts. -- dwmw2 From bpepple at fedoraproject.org Wed Apr 25 22:53:04 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 25 Apr 2007 18:53:04 -0400 Subject: Plan for tomorrows (20070426) FESCO meeting Message-ID: <1177541584.17572.3.camel@lincoln> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop /topic FESCO-Meeting -- new sponsor nominations anyone? /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- F7 preparation /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- EPEL /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 sundaram at fedoraproject.org Wed Apr 25 22:59:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 26 Apr 2007 04:29:24 +0530 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <1177541584.17572.3.camel@lincoln> References: <1177541584.17572.3.camel@lincoln> Message-ID: <462FDD4C.30801@fedoraproject.org> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, > rdieter, tibbs, scop > > /topic FESCO-Meeting -- new sponsor nominations anyone? > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-Meeting -- MISC -- F7 preparation > > /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb > > /topic FESCO-Meeting -- EPEL > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. Few things: * Discuss which of the policies documented in http://fedoraproject.org/wiki/PackageMaintainers/Policy are still relevant and applicable and update it to cover the whole repository. * Policy (such as licensing) is intermixed in the packaging guidelines too. Decide which ones are to separated out. * Decide on a place to post meeting mins and how to do it. I would suggest under http://fedoraproject.org/wiki/Development/. There was some discussions about not posting meeting logs in the wiki but post to mailing list and point to it from the wiki to avoid scalability issues. If you are going to continue posting to the wiki, irclog2html like Release Engineering meetings at http://fedoraproject.org/wiki/ReleaseEngineering/. I find it more readable. Rahul From petersen at redhat.com Wed Apr 25 23:43:39 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 26 Apr 2007 09:43:39 +1000 Subject: Fedora 7: SCIM Launch Problem In-Reply-To: <462E301F.6000509@redhat.com> References: <462660F6.2070909@redhat.com> <462BFC8A.4090704@redhat.com> <462D057A.30802@redhat.com> <462DA0EF.80504@redhat.com> <462E301F.6000509@redhat.com> Message-ID: <462FE7AB.6070706@redhat.com> Warren Togami wrote: > Jens Petersen wrote: >> I'll update scim later since the >> changes should actually be in the system config file not the hardcoded >> default. > But is that particular change to SCIM the right thing to do? Yes because it is currently not possible to unset the hotkey. ;) > I think it is wrong because it creates an inconsistency in configuration. I don't understand this comment. > We should instead think about the default hotkey itself first? I am sometimes tempted to just not set a default hotkey at all and so let users choose their own. Jens From dev at nigelj.com Wed Apr 25 23:54:47 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 26 Apr 2007 11:54:47 +1200 (NZST) Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <1177541584.17572.3.camel@lincoln> References: <1177541584.17572.3.camel@lincoln> Message-ID: <62606.202.154.144.162.1177545287.squirrel@webmail.nigelj.com> > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- Packaging Committee Report -- spot, abadger1999, > rdieter, tibbs, scop > > /topic FESCO-Meeting -- new sponsor nominations anyone? > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-Meeting -- MISC -- F7 preparation > > /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb > > /topic FESCO-Meeting -- EPEL > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. If possible could the discussion of allowing camlimages, ocamlSDL and freetennis (all pending review) [1][2][3] to be packaged with static libraries be discussed during the next meeting? I most likely can't attend due to the meeting time, but I'd really appreciate a decision. A bit of background on the issue: While packaging freetennis, I discovered missing dependencies in the repository, and decided to package ocamlSDL and camlimages to allow building on freetennis, upon inspecting the dependencies of all the rpms, it seemed suspect and I posted a trailing note at the bottom of the review requests, and then posted a message to fedora-packaging [4][5] receiving a 'possible ok' response from Toshio [6] (as clarification to Toshio's post, I believe that dynamic linking is possible under certain conditions, but it requires changes to the program source, which I may look at doing if ocaml continues to not allow dynamic linking). I filed a bug against ocaml [7] to get the maintainer to look at solutions for this problem, but nothing seems to have been done. (I'd tested an unmaintained patch against the fedora version, which failed miserably in ways that I was not comfortable fixing). So yeah, if that can be discussed at some point, I would really appreciate it. > > If your name/nick is on above list please update the status on the > Extras schedule pages in the wiki ahead of the meeting. That way all the > other FESCo members and interested contributors know what up ahead of > the meeting. And we will avoid long delays in the meeting -- those often > arise if someone describes the recent happenings on a topic directly in > the meeting while all the others have to wait for his slow typing... > > Thanks, > /B > -- > Brian Pepple > > gpg --keyserver pgp.mit.edu --recv-keys 810CC15E > BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815 [4] https://www.redhat.com/archives/fedora-packaging/2007-April/msg00100.html [5] https://www.redhat.com/archives/fedora-packaging/2007-April/msg00164.html [6] https://www.redhat.com/archives/fedora-packaging/2007-April/msg00170.html [7] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236497 From fedora at leemhuis.info Thu Apr 26 05:35:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Apr 2007 07:35:34 +0200 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <462FDD4C.30801@fedoraproject.org> References: <1177541584.17572.3.camel@lincoln> <462FDD4C.30801@fedoraproject.org> Message-ID: <46303A26.8020402@leemhuis.info> Rahul Sundaram schrieb: > Brian Pepple wrote: > > * Decide on a place to post meeting mins and how to do it. I would > suggest under http://fedoraproject.org/wiki/Development/. There was some > discussions about not posting meeting logs in the wiki but post to > mailing list and point to it from the wiki to avoid scalability issues. In case anybody is wondering -- that discussion started here: https://www.redhat.com/archives/fedora-websites-list/2007-April/msg00014.html and ended at https://www.redhat.com/archives/fedora-websites-list/2007-April/msg00029.html where Patrick "The N-Man" Barnes wrote: "If nobody has any big reason against it, we can call it policy right now. We just have to make sure that the people posting the meeting minutes are aware of it. :-)" BTW, IMHO it are less scalability issues (but we'll probably run into those sooner or later, too, if X groups add Y logs per week into the wiki). It's more a "it IMHO makes the wiki search engine much harder to use as you often find old meeting summaries instead of the up2date guidelines or whatever else you searched for" Anyway: having them in the wiki has some benefits, too. But maybe we should delete them somewhen to avoid that old cruft fills the wiki and makes the searching much useless. How about this: We put them in the wiki as "Meeting of week X" pages and thus simply overwrite them after one year? The old versions then will still be accessible via the "info" button and up2date decisions and discussions are found via the search engine, but older ones are not. Or maybe this: we have a script deletes old meeting logs -- then they are also still available if there is a need to, but not searched. > If you are going to continue posting to the wiki, irclog2html like > Release Engineering meetings at > http://fedoraproject.org/wiki/ReleaseEngineering/. I find it more readable. +1 CU thl From fedora at leemhuis.info Thu Apr 26 07:15:06 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Apr 2007 09:15:06 +0200 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <1177541584.17572.3.camel@lincoln> References: <1177541584.17572.3.camel@lincoln> Message-ID: <4630517A.2030003@leemhuis.info> Brian Pepple schrieb: > > /topic FESCO-Meeting -- EPEL There was no meeting this week afaics from looking at #fedora-meeting. Other stuff: There was and still is a lot of political discussions on the mailing list about EPEL not using a repotag. Please see fedora-devel for details, as I'd like to see the issue discussed on a public mailig list, and not this one, as it is only open for contributors. CU thl From pertusus at free.fr Thu Apr 26 07:24:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 26 Apr 2007 09:24:15 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425174535.GB12287@ryvius.pekin.waw.pl> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> Message-ID: <20070426072415.GC5296@free.fr> On Wed, Apr 25, 2007 at 07:45:36PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > Those should be in a -devel package and libs should > be split off, too. Clearly a packaging bug. It is fixed now, but the timestamp issue may still be there (I havent't checked). -- Pat From pertusus at free.fr Thu Apr 26 07:29:23 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 26 Apr 2007 09:29:23 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425173942.GU11831@neu.nirvana> References: <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> Message-ID: <20070426072923.GD5296@free.fr> On Wed, Apr 25, 2007 at 07:39:42PM +0200, Axel Thimm wrote: > > Yes, but it does involve much more work to do. And if we assume that > every package is in principle candidate for multilib, we would end > with a guidelines to have all packages using bindir to split off > subpackages. The setting _bindir=/usr/bin64 would already fix the > majority of packages w/o having to touhc the specfile. But it will end up, on x86_64 with the binaries for the primary arch not to be in the classical paths. Wouldn't it better to have _bindir=/usr/bin32 for 32 bit apps? > > Except if they have the same md5 sum? > > Yes and no. One can discuss the usefulness of mtime verification (I > personally think it is useful, and I think the packages can be made to > have the same timestamps on both archs, just use install -p and for > generated files use touch -r from the master files), but there is far > more important metadata like owner/group and mode of the files that > should never be ignored and allowed to conflict. I agree that diferent owner/group and mode of the files should trigger a conflict. For timestamps it is a goal for packaging to keep them and have them identical on both arches, but I don't think it should create a conflict at install time. Some are not easy to avoid, like build time generated documentation. -- Pat From Axel.Thimm at ATrpms.net Thu Apr 26 08:16:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 10:16:58 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426072923.GD5296@free.fr> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> Message-ID: <20070426081658.GC23704@neu.nirvana> On Thu, Apr 26, 2007 at 09:29:23AM +0200, Patrice Dumas wrote: > On Wed, Apr 25, 2007 at 07:39:42PM +0200, Axel Thimm wrote: > > > > Yes, but it does involve much more work to do. And if we assume that > > every package is in principle candidate for multilib, we would end > > with a guidelines to have all packages using bindir to split off > > subpackages. The setting _bindir=/usr/bin64 would already fix the > > majority of packages w/o having to touhc the specfile. > > But it will end up, on x86_64 with the binaries for the primary arch not > to be in the classical paths. Wouldn't it better to have > _bindir=/usr/bin32 for 32 bit apps? No, because you want to reuse the packages from i386 that will already occupy /usr/bin. /usr/bin32 for i386 would imply that o either all packages in i386 are rebuilt for i386 to place their bins there, too, and then your argument of not a classical path would apply to all i386 system, which outweigh the x86_64 ones, or o You have different i386 packages for i386 and x86_64, which is also not a good solution, because you lose the QA for the pure i386 packages. > > > Except if they have the same md5 sum? > > > > Yes and no. One can discuss the usefulness of mtime verification (I > > personally think it is useful, and I think the packages can be made to > > have the same timestamps on both archs, just use install -p and for > > generated files use touch -r from the master files), but there is far > > more important metadata like owner/group and mode of the files that > > should never be ignored and allowed to conflict. > > I agree that diferent owner/group and mode of the files should trigger > a conflict. For timestamps it is a goal for packaging to keep them and > have them identical on both arches, but I don't think it should create a > conflict at install time. Some are not easy to avoid, like build time > generated documentation. mtime doesn't create conflicts AFAIK, it is just visibly in rpm --verify. But ideally, as you say, the packages should be fixed to have proper timestamps, and see above for a way on how to deal with the problem of generated documentation. -- 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 Thu Apr 26 08:24:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 10:24:18 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177534980.2755.265.camel@pmac.infradead.org> References: <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> Message-ID: <20070426082418.GD23704@neu.nirvana> On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > [... Changing all specfiles by splitting out bin subpackages > > > > vs simply defining a new _bindir ...] > > > Yes, but it does involve much more work to do. > > Packaging is hard. Let's go shopping. No, the above is not hard to do, it is a straightforward thing to do that will occupy a full or more than one release cycle(s). I prefer to get F8 with some new features as well and not only a mass review again. Which wil involve thre times as many packages as the FC merge review which we didn't manage to finish. A better F8 and even time for you to go shipping. Win-win. > It helps a little bit if we fix RPM to actually make the _right_ > decision when it's forced to choose between conflicting files > (http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch), but really, RPM > shouldn't be making those decisions. Indeed. > It should just be installing what it's told to, and it shouldn't be > told to install stuff which conflicts. Agreed. But in your proposal of splitting out all bin parts, the bin parts would still conflict, so no /usr/bin/firefox and no /usr/bin64/firefox. Instead with the simply _bindir redefinition you save time, go shopping and can coinstall binaries of both archs. Win-win-win. BTW I hate shopping, if your proposal makes it easier not having to go shopping, then let's do it your 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 dwmw2 at infradead.org Thu Apr 26 08:56:33 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Apr 2007 09:56:33 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426082418.GD23704@neu.nirvana> References: <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> Message-ID: <1177577793.2755.303.camel@pmac.infradead.org> On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > vs simply defining a new _bindir ...] > > > > Yes, but it does involve much more work to do. > > > > Packaging is hard. Let's go shopping. > > No, the above is not hard to do, it is a straightforward thing to do > that will occupy a full or more than one release cycle(s). > > I prefer to get F8 with some new features as well and not only a mass > review again. Which wil involve thre times as many packages as the FC > merge review which we didn't manage to finish. Actually, this one should be quite easy to automate. We've spent too long trying to take short-cuts and do the easiest thing in the _short_ term for multilib -- and it shows. It's time to start doing it properly, IMHBCO. I'll entertain discussion about whether banning these conflicts is 'proper', but with all due respect I'm not too interested in discussion about the fact that it might actually take a small amount of work to fix the packaging so that we can remove this dirty problematic filecolours hack from RPM. Packaging is hard. Let's go sailing. > > RPM shouldn't be making those decisions. > > Indeed. > > > It should just be installing what it's told to, and it shouldn't be > > told to install stuff which conflicts. > > Agreed. But in your proposal of splitting out all bin parts, the bin > parts would still conflict, so no /usr/bin/firefox and no > /usr/bin64/firefox. That's true (well, actually not for firefox right now but we plan to fix that and eliminate the shell script in /usr/bin). But that's because we've never really had 'coinstall _binaries_ of both architectures' as a goal of our multilib support. It's multilib, not multibin. Multilib is about coinstalling libraries for both runtime and development purposes -- but not binaries. That's a new requirement, and not something we've ever tried before. I don't think we can manage it within the scope of the LSB. However, we _can_ let the user choose which binary is installed in /usr/bin. And perhaps we can let them install the other one with --relocate? Do we really want to let them install both? -- dwmw2 From Axel.Thimm at ATrpms.net Thu Apr 26 09:21:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 11:21:01 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177577793.2755.303.camel@pmac.infradead.org> References: <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> Message-ID: <20070426092101.GE23704@neu.nirvana> On Thu, Apr 26, 2007 at 09:56:33AM +0100, David Woodhouse wrote: > On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > > vs simply defining a new _bindir ...] > > > > > Yes, but it does involve much more work to do. > > > > > > Packaging is hard. Let's go shopping. > > > > No, the above is not hard to do, it is a straightforward thing to do > > that will occupy a full or more than one release cycle(s). > > > > I prefer to get F8 with some new features as well and not only a mass > > review again. Which wil involve thre times as many packages as the FC > > merge review which we didn't manage to finish. > > Actually, this one should be quite easy to automate. > > We've spent too long trying to take short-cuts and do the easiest thing > in the _short_ term for multilib -- and it shows. It's time to start > doing it properly, IMHBCO. Exactly and the proper thing for multilib is: Let it die, multiarch rulez! > I'll entertain discussion about whether banning these conflicts is > 'proper', but with all due respect I'm not too interested in discussion > about the fact that it might actually take a small amount of work to fix > the packaging so that we can remove this dirty problematic filecolours > hack from RPM. You misunderstood me, I'm all for removing all special support in rpm. That's why I propose to fix this at a lower level than rpm, so rpm has nothing to solve anymore. > Packaging is hard. Let's go sailing. No, you're full of free time activities, how about Packaging is fun, let's go package new stuff, and not repackage old for the umpteenth time? > > > RPM shouldn't be making those decisions. > > > > Indeed. > > > > > It should just be installing what it's told to, and it shouldn't be > > > told to install stuff which conflicts. > > > > Agreed. But in your proposal of splitting out all bin parts, the bin > > parts would still conflict, so no /usr/bin/firefox and no > > /usr/bin64/firefox. > > That's true (well, actually not for firefox right now but we plan to fix > that and eliminate the shell script in /usr/bin). But that's because > we've never really had 'coinstall _binaries_ of both architectures' as a > goal of our multilib support. It's multilib, not multibin. It's called multiarch, not multibin. And that was the main problem with multilib and shortcut solutions: multilib was the shortcut solution, and implied all the pain of the last years. Ditch multilib for good, go multiarch and forget about rpm special handling, punched install/remove holes (that are firmly embedded in the multilib design) and all the multilib pain. It sounds like more changes/work than it actually is. > Multilib is about coinstalling libraries for both runtime and > development purposes -- but not binaries. That's a new requirement, > and not something we've ever tried before. It's not really a requirement, but yet another nice side-effect. > I don't think we can manage it within the scope of the LSB. However, we > _can_ let the user choose which binary is installed in /usr/bin. And > perhaps we can let them install the other one with --relocate? Ouch, no, please, no relocate, 99% of open source software projects don't support this. This is mainly a mechanism for ISVs that do make their software relocatable as their ship it in closed source and the user need to be able to move it around in /opt or whereever he need it. > Do we really want to let them install both? If they want to. It shouldn't be the default, though. Just ask who the target users of multilib (or multiarch) are. For quite some time we assumed only users that wanted to have runtime support for a couple not ported parts. Later we discovered that developers want to use this platform (w/o chroots) and started the *-devel hacks. So it is natural to assume that these developers and user may even want to run their bits in a packaged form and not just under /ustr/local. The bin64 proposal has many merits, the main drawback is FHS/LSB, but these institutions are not our enemies, part of doing this step would be to involve them, explain the motivations and ask for supporting the new model as well (which isn't new, but anyway). We are already violating the FHS due to multilib (libexec) and it is difficult to even explain the implication to non-multilibers that lead to libexec != libdir/%{name}. Going multiarch would allow us to drop libexec, so we'd be just replacing one violation with another currently. -- 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 dwmw2 at infradead.org Thu Apr 26 09:33:48 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Apr 2007 10:33:48 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426092101.GE23704@neu.nirvana> References: <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> Message-ID: <1177580028.2755.322.camel@pmac.infradead.org> On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote: > It's called multiarch, not multibin. > > And that was the main problem with multilib and shortcut solutions: > multilib was the shortcut solution, and implied all the pain of the > last years. Not _all_ of the pain. A lot of the pain came from making stupid short-term decisions, like the filecolour hack in RPM which we're currently referring to. There was never any need for that, except perhaps as a short-term hack. Multilib _really_ doesn't need to be as painful as it has been in the past, if we start thinking about it a little more coherently. > Ditch multilib for good, go multiarch and forget about rpm special > handling, punched install/remove holes (that are firmly embedded in > the multilib design) and all the multilib pain. 'punched install/remove holes'? > It sounds like more changes/work than it actually is. I'm listening.... be specific. How does it work? -- dwmw2 From chitlesh at fedoraproject.org Thu Apr 26 09:45:47 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 26 Apr 2007 11:45:47 +0200 Subject: buildsys: Error: could not make srpm Message-ID: <13dbfe4f0704260245k46883e99sa05fe28ec44e2d9d@mail.gmail.com> Hello there, the buildsys can't find the source tarball of ktechlab for some reason beyond my knowledge. http://buildsys.fedoraproject.org/build-status/job.psp?uid=32493 Error: could not make srpm for ktechlab-0_3_6-2_fc5 - output was: Downloading ktechlab-0.3.6.tar.bz2... --04:39:22-- http://cvs.fedora.redhat.com/repo/extras/ktechlab/ktechlab-0.3.6.tar.bz2/0cc2f2054f7906780c8580560f04b0ff/ktechlab-0.3.6.tar.bz2 => `ktechlab-0.3.6.tar.bz2' Resolving cvs.fedora.redhat.com... 209.132.176.51 Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. HTTP request sent, awaiting response... 404 Not Found 04:39:22 ERROR 404: Not Found. FINISHED --04:39:22-- Downloaded: 0 bytes in 0 files Could not download source file: ktechlab-0.3.6.tar.bz2 does not exist make: *** [ktechlab-0.3.6.tar.bz2] Error 1 I've sent ktechlab's srpm with ./common/cvs-import.sh script. However I just submitted and built "crystal" successfully through the same procedures. regards, Chitlesh -- http://clunixchit.blogspot.com From pertusus at free.fr Thu Apr 26 10:11:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 26 Apr 2007 12:11:45 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426081658.GC23704@neu.nirvana> References: <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> Message-ID: <20070426101145.GG5296@free.fr> On Thu, Apr 26, 2007 at 10:16:58AM +0200, Axel Thimm wrote: > On Thu, Apr 26, 2007 at 09:29:23AM +0200, Patrice Dumas wrote: > > > > But it will end up, on x86_64 with the binaries for the primary arch not > > to be in the classical paths. Wouldn't it better to have > > _bindir=/usr/bin32 for 32 bit apps? > > No, because you want to reuse the packages from i386 that will already > occupy /usr/bin. /usr/bin32 for i386 would imply that > > o either all packages in i386 are rebuilt for i386 to place their bins > there, too, and then your argument of not a classical path would > apply to all i386 system, which outweigh the x86_64 ones, or This is clearly out of question. > o You have different i386 packages for i386 and x86_64, which is also > not a good solution, because you lose the QA for the pure i386 > packages. In my opinion having preferred arch binaries not in *bin/ is also not very clean in my opinion. I personally think that I'd prefer to have the preferred arch binaries in *bin/ and therefore different builds on i386 and x86_64 for 32 bit packages. This is debatable, since it implies a change in the build infrastructure, another repo for i386 on x86_64. I think that it should be nice if there was a consensus on that multiarch idea, but I also think that we shouldn't rush to a specific solution, in the mean time we should try to have a multilib system without conflicts. > mtime doesn't create conflicts AFAIK, it is just visibly in rpm > --verify. But ideally, as you say, the packages should be fixed to > have proper timestamps, and see above for a way on how to deal with > the problem of generated documentation. You mean above in the thread? I missed it, but I'll search. -- Pat From jakub at redhat.com Thu Apr 26 10:21:40 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 26 Apr 2007 06:21:40 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070425165221.GO11831@neu.nirvana> References: <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> Message-ID: <20070426102140.GI355@devserv.devel.redhat.com> On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote: > > So having both /bin/ls and /bin64/ls serves no useful purpose > > Consider (*) > > yum install foo.i386 > yum install foo.x86_64 > yum remove foo.x86_64 > rpm -V foo > (same for smart and apt) > > The current multilib model in rpm with blindly overwriting files is > broken by design (e.g. unfixable in shared bindir environments). You > cannot consider the packaging system a stateless machine anymore. > > Adding to the design issues there are also implementation bugs with > %docs and %langs that get uninstalled when the i386 package gets > uninstalled and so on. Furthermore foo.i386 and foo.x86_64 packages > often alread conflict on other files which is silently muted during > coinstallation. That's all solvable in the package management or by packaging decisions (basically split current packages into subpackages based on the current %_filecolor - color 0 (aka binaries and data files) would generally stay in the packages, color != 0 (primarily libraries) would go into new subpackages (*-lib or *-libs or something). I believe this is what dwmw2 is envisioning. Even with current %_filecolor the above is solvable, if you have both foo-1.2.3-6.i386 and foo-1.2.3-6.x86_64 installed and they have color 0 files with different content between the arches, to remove foo-1.2.3-6.x86_64 and keep foo-1.2.3-6.i386 all you really need is to be able to recreate those 32-bit files. You are proposing */{,s}bin64 basically as a filesystem cache for such a rare operation. As I wrote, with at most a dozen exceptions per distro you really don't need every binary twice, the binaries have identical behavior and all they perhaps differ in is speed (so you just need to choose the faster one, not install both and let the poor user choose which exactly they want to run). But you can easily recreate the files also from the original foo-1.2.3-6.i386.rpm. Either you still have it in say yum's cache, or download it again, what you write above is not something everybody is doing every day. On the filesystem people really want multilib, not multibin or multiarch you are proposing. It works in multiple OSes and has been in use for years (Irix, Solaris, Linux). Jakub From pertusus at free.fr Thu Apr 26 10:18:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 26 Apr 2007 12:18:38 +0200 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <62606.202.154.144.162.1177545287.squirrel@webmail.nigelj.com> References: <1177541584.17572.3.camel@lincoln> <62606.202.154.144.162.1177545287.squirrel@webmail.nigelj.com> Message-ID: <20070426101838.GH5296@free.fr> On Thu, Apr 26, 2007 at 11:54:47AM +1200, Nigel Jones wrote: > If possible could the discussion of allowing camlimages, ocamlSDL and > freetennis (all pending review) [1][2][3] to be packaged with static > libraries be discussed during the next meeting? I most likely can't > attend due to the meeting time, but I'd really appreciate a decision. I know that it isn't what is said in the guidelines, in the guidelines it is said that FESCo should approve such things, but in my opinion you should make your choice as a packager without waiting for FESCo, since in this case this is a limitation imposed by upstream. Now if there is a dispute within reviewers then FESCo is needed but if no reviewer objects for using the static libs, I'd say just do it without waiting for FESCo. Of course, if FESCo members after looking at the issue have a different opinion you should reconsider, but I can't see how it could be the case. -- Pat From pertusus at free.fr Thu Apr 26 10:20:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 26 Apr 2007 12:20:03 +0200 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <1177541584.17572.3.camel@lincoln> References: <1177541584.17572.3.camel@lincoln> Message-ID: <20070426102003.GI5296@free.fr> On Wed, Apr 25, 2007 at 06:53:04PM -0400, Brian Pepple wrote: > Hi, > Maybe the issue of multilib/conflicting binaries/using *bin64 could be discussed? (It would be for F8, of course, but better start sooner than later). -- Pat From dwmw2 at infradead.org Thu Apr 26 10:29:46 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Apr 2007 11:29:46 +0100 Subject: Spilt libperl from perl In-Reply-To: <1177357164.5956.23.camel@localhost.localdomain> References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> Message-ID: <1177583386.2755.340.camel@pmac.infradead.org> On Mon, 2007-04-23 at 14:39 -0500, Tom "spot" Callaway wrote: > I'm not going to support making a libperl subpackage to dodge fixing > multilib. By doing this, we just slide down the slippery slope of > avoiding the problem, and relying on dirty hacks instead of solving > the hard problems. I believe you retracted this on IRC, after I pointed out that this is actually the _fix_ to avoid the dirty hack in RPM which allows the installation of conflicting files. You said we'd go ahead and split the package. But it doesn't seem to have been done yet -- are we still going ahead with it? If not (and in fact even if we do), we need to at least fix said dirty hack in RPM so that it doesn't favour binaries of the secondary architecture. There's a patch which makes RPM honour a %_prefer_color macro at http://david.woodhou.se/rpm-4.4.2-prefer-elf32.patch With that fixed (and with anaconda setting %_prefer_color of course), and with the yum fix I just attached to bug 233427, I've just done a test install which looks a _whole_ lot better. I can 'yum remove glibc.ppc64 libgcc.ppc64' and it no longer wants to remove important stuff of the primary architecture, like initscripts.ppc :) Of course, it's still a bug (#235756) that we're installing all that crap for the secondary architecture by _default_ when almost nobody wants it. But at least with the minimal fixes we can get rid of it afterwards. Those minimal fixes don't affect non-ppc, and should be entirely safe for F7. -- dwmw2 From kwizart at gmail.com Thu Apr 26 10:37:16 2007 From: kwizart at gmail.com (KH KH) Date: Thu, 26 Apr 2007 12:37:16 +0200 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <20070426102003.GI5296@free.fr> References: <1177541584.17572.3.camel@lincoln> <20070426102003.GI5296@free.fr> Message-ID: Hello! I would like to ask which is the current status of firmware distribution (Wifi) I don't know for example if iwlwifi-firmware will be bundled, so laptops with ipw3945 chipset could work "out of the box" (depending on status with the last kernel) In such case: it would be good to bundle also zd1211-firmware, which have been reported to work fine... Other Ralink firmware status is unknow for now ... (still in review process - but upstream do not bundle any license with it) Nicolas (kwizart) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Thu Apr 26 10:55:49 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 Apr 2007 12:55:49 +0200 Subject: buildsys: Error: could not make srpm In-Reply-To: <13dbfe4f0704260245k46883e99sa05fe28ec44e2d9d@mail.gmail.com> References: <13dbfe4f0704260245k46883e99sa05fe28ec44e2d9d@mail.gmail.com> Message-ID: <20070426125549.8b768456.bugs.michael@gmx.net> On Thu, 26 Apr 2007 11:45:47 +0200, Chitlesh GOORAH wrote: > Hello there, > > the buildsys can't find the source tarball of ktechlab for some reason > beyond my knowledge. > http://buildsys.fedoraproject.org/build-status/job.psp?uid=32493 > > Error: could not make srpm for ktechlab-0_3_6-2_fc5 - output was: > Downloading ktechlab-0.3.6.tar.bz2... > --04:39:22-- http://cvs.fedora.redhat.com/repo/extras/ktechlab/ktechlab-0.3.6.tar.bz2/0cc2f2054f7906780c8580560f04b0ff/ktechlab-0.3.6.tar.bz2 > => `ktechlab-0.3.6.tar.bz2' > Resolving cvs.fedora.redhat.com... 209.132.176.51 > Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 04:39:22 ERROR 404: Not Found. > FINISHED --04:39:22-- > Downloaded: 0 bytes in 0 files > Could not download source file: ktechlab-0.3.6.tar.bz2 does not exist > make: *** [ktechlab-0.3.6.tar.bz2] Error 1 > > I've sent ktechlab's srpm with ./common/cvs-import.sh script. However > I just submitted and built "crystal" successfully through the same > procedures. Does a manual upload with "make new-sources FILES=ktechlab-0.3.6.tar.bz2" work for you? From nicolas.mailhot at laposte.net Thu Apr 26 10:54:46 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 26 Apr 2007 12:54:46 +0200 (CEST) Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426081658.GC23704@neu.nirvana> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> Message-ID: <28084.192.54.193.51.1177584886.squirrel@rousalka.dyndns.org> > o You have different i386 packages for i386 and x86_64, which is also > not a good solution, because you lose the QA for the pure i386 > packages. not if you use bin32 on i386 too, making bin a symlink to the primary arch -- Nicolas Mailhot From fedora at leemhuis.info Thu Apr 26 10:56:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Apr 2007 12:56:45 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070426102140.GI355@devserv.devel.redhat.com> References: <20070423195526.GA17157@nostromo.devel.redhat.com> <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070426102140.GI355@devserv.devel.redhat.com> Message-ID: <4630856D.8070908@leemhuis.info> Jakub Jelinek schrieb: > On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote: > [...] > On the filesystem people really want multilib, not multibin or multiarch > you are proposing. [...] As a long term x86_64-user (nearly right after the first Opterons got out) I tend to agree. But the reason why I'm sending this mail is this: What Axel outlined is afaics a nice concept for a true multibin/multiarch system. Maybe something like that should have been defined in addition to multilib years ago. But it wasn't. Maybe (I don't think so, but that doesn't matter much for the rest of this mail) it's still worth to define something like that and write a spec for it. But doing something big like that only in Fedora seem utterly wrong to me and makes us to much "special" and different from others. If something like that really is wanted it IMHO should be done in cooperation with other distros and/or the LSB, as changes like {/usr,}/{s,}bin64 breaks a lot of expectations and requirements people, apps and scripts currently have. Just my 2 cent. CU thl From dev at nigelj.com Thu Apr 26 11:07:27 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 26 Apr 2007 23:07:27 +1200 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <20070426101838.GH5296@free.fr> References: <1177541584.17572.3.camel@lincoln> <62606.202.154.144.162.1177545287.squirrel@webmail.nigelj.com> <20070426101838.GH5296@free.fr> Message-ID: <463087EF.6050905@nigelj.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrice Dumas wrote: > On Thu, Apr 26, 2007 at 11:54:47AM +1200, Nigel Jones wrote: >> If possible could the discussion of allowing camlimages, ocamlSDL and >> freetennis (all pending review) [1][2][3] to be packaged with static >> libraries be discussed during the next meeting? I most likely can't >> attend due to the meeting time, but I'd really appreciate a decision. > > I know that it isn't what is said in the guidelines, in the guidelines > it is said that FESCo should approve such things, but in my opinion you > should make your choice as a packager without waiting for FESCo, since in > this case this is a limitation imposed by upstream. Now if there is a > dispute within reviewers then FESCo is needed but if no reviewer objects for > using the static libs, I'd say just do it without waiting for FESCo. Of > course, if FESCo members after looking at the issue have a different > opinion you should reconsider, but I can't see how it could be the case. Okay then, I'll post a note to the 3 bugs soon, and see what happens. - -- N.J. > > -- > Pat > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGMIfvpldg9bRmG6kRAt9RAKCAsBaVi+7MsQ2th9a55P9loQf1OgCdE/Gz 0WRdcmW7fSSDI3y2SDyE6NE= =8W9R -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Thu Apr 26 11:13:25 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 13:13:25 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177580028.2755.322.camel@pmac.infradead.org> References: <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> Message-ID: <20070426111325.GH23704@neu.nirvana> On Thu, Apr 26, 2007 at 10:33:48AM +0100, David Woodhouse wrote: > On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote: > > It's called multiarch, not multibin. > > > > And that was the main problem with multilib and shortcut solutions: > > multilib was the shortcut solution, and implied all the pain of the > > last years. > > Not _all_ of the pain. A lot of the pain came from making stupid > short-term decisions, like the filecolour hack in RPM which we're > currently referring to. There was never any need for that, except > perhaps as a short-term hack. Which is only needed once you start allowing (in your concept) files of one "color" to be overwritable by another. If you put at the top of your specs that you won't allow any multilib/multiarch/multifoo design to allow for such dirty tricks then you don't need that anymore. And that's what the bindir=>bin64 proposal does. > Multilib _really_ doesn't need to be as painful as it has been in the > past, if we start thinking about it a little more coherently. Agreed. > > Ditch multilib for good, go multiarch and forget about rpm special > > handling, punched install/remove holes (that are firmly embedded in > > the multilib design) and all the multilib pain. > > 'punched install/remove holes'? See a prvious mail, but for the sake of context: yum install foo.i386 yum install foo.x86_64 yum remove foo.x86_64 rpm -V foo Many punched holes, there is no state machine reliability in rpm by (multilib) design. You can only get that wokring if you don't allow foo.i386 and foo.x86_64 to contain conflicting files, e.g. move your bins to different folders. Then (package bugs aside) you can install/remove as you wish and the result is history-free. > > It sounds like more changes/work than it actually is. > > I'm listening.... be specific. How does it work? -%_bindir %{_exec_prefix}/bin -%_sbindir %{_exec_prefix}/sbin -%_libexecdir %{_exec_prefix}/libexec +%_bindir %{_exec_prefix}/bin64 +%_sbindir %{_exec_prefix}/sbin64 +%_libexecdir %{_exec_prefix}/%{_lib} And sure, there will be packages with hardcoded bindirs to /usr/bin, which we'll automatically detect on the first 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 Axel.Thimm at ATrpms.net Thu Apr 26 11:15:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 13:15:22 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426101145.GG5296@free.fr> References: <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> <20070426101145.GG5296@free.fr> Message-ID: <20070426111522.GI23704@neu.nirvana> On Thu, Apr 26, 2007 at 12:11:45PM +0200, Patrice Dumas wrote: > On Thu, Apr 26, 2007 at 10:16:58AM +0200, Axel Thimm wrote: > > On Thu, Apr 26, 2007 at 09:29:23AM +0200, Patrice Dumas wrote: > > > > > > But it will end up, on x86_64 with the binaries for the primary arch not > > > to be in the classical paths. Wouldn't it better to have > > > _bindir=/usr/bin32 for 32 bit apps? > > > > No, because you want to reuse the packages from i386 that will already > > occupy /usr/bin. /usr/bin32 for i386 would imply that > > > > o either all packages in i386 are rebuilt for i386 to place their bins > > there, too, and then your argument of not a classical path would > > apply to all i386 system, which outweigh the x86_64 ones, or > > This is clearly out of question. > > > o You have different i386 packages for i386 and x86_64, which is also > > not a good solution, because you lose the QA for the pure i386 > > packages. > > In my opinion having preferred arch binaries not in *bin/ is also not very > clean in my opinion. I personally think that I'd prefer to have the > preferred arch binaries in *bin/ and therefore different builds on > i386 and x86_64 for 32 bit packages. This is debatable, since it implies > a change in the build infrastructure, another repo for i386 on > x86_64. The point was that we want to lower the troubles by simply allowing users to point to the normal i386 repo, not rebuild i386 twice. :/ > I think that it should be nice if there was a consensus on that > multiarch idea, but I also think that we shouldn't rush to a specific > solution, in the mean time we should try to have a multilib system > without conflicts. > > > mtime doesn't create conflicts AFAIK, it is just visibly in rpm > > --verify. But ideally, as you say, the packages should be fixed to > > have proper timestamps, and see above for a way on how to deal with > > the problem of generated documentation. > > You mean above in the thread? I missed it, but I'll search. It was in the quote you just trimmed: install -p and touch -r. For generated stuff use the latter. But I agree the mtime issue is not as important. -- 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 Thu Apr 26 11:16:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 13:16:18 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <28084.192.54.193.51.1177584886.squirrel@rousalka.dyndns.org> References: <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> <28084.192.54.193.51.1177584886.squirrel@rousalka.dyndns.org> Message-ID: <20070426111618.GJ23704@neu.nirvana> On Thu, Apr 26, 2007 at 12:54:46PM +0200, Nicolas Mailhot wrote: > > o either all packages in i386 are rebuilt for i386 to place their bins > > there, too, and then your argument of not a classical path would > > apply to all i386 system, which outweigh the x86_64 ones, or > > o You have different i386 packages for i386 and x86_64, which is also > > not a good solution, because you lose the QA for the pure i386 > > packages. > > not if you use bin32 on i386 too, making bin a symlink to the primary > arch That would be the first case. -- 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 Thu Apr 26 11:30:01 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 13:30:01 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426102140.GI355@devserv.devel.redhat.com> References: <462D152F.7060607@hhs.nl> <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070426102140.GI355@devserv.devel.redhat.com> Message-ID: <20070426113001.GK23704@neu.nirvana> On Thu, Apr 26, 2007 at 06:21:40AM -0400, Jakub Jelinek wrote: > On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote: > > > So having both /bin/ls and /bin64/ls serves no useful purpose > > > > Consider (*) > > > > yum install foo.i386 > > yum install foo.x86_64 > > yum remove foo.x86_64 > > rpm -V foo > > (same for smart and apt) > > > > The current multilib model in rpm with blindly overwriting files is > > broken by design (e.g. unfixable in shared bindir environments). You > > cannot consider the packaging system a stateless machine anymore. > > > > Adding to the design issues there are also implementation bugs with > > %docs and %langs that get uninstalled when the i386 package gets > > uninstalled and so on. Furthermore foo.i386 and foo.x86_64 packages > > often alread conflict on other files which is silently muted during > > coinstallation. > > That's all solvable in the package management or by packaging decisions Not really, as you later explain, you would have to recreate the punched out files in the current model. > (basically split current packages into subpackages based on the current > %_filecolor - color 0 (aka binaries and data files) would generally stay > in the packages, color != 0 (primarily libraries) would go into new > subpackages (*-lib or *-libs or something). I believe this is what > dwmw2 is envisioning. Even with current %_filecolor the above is solvable, > if you have both foo-1.2.3-6.i386 and foo-1.2.3-6.x86_64 installed and > they have color 0 files with different content between the arches, > to remove foo-1.2.3-6.x86_64 and keep foo-1.2.3-6.i386 all you really need > is to be able to recreate those 32-bit files. Exactly, and if we would have to add this to rpm, too, then God beware of the breakage in rpm. > You are proposing */{,s}bin64 basically as a filesystem cache for > such a rare operation. Not only, consider the above being firefox or somethign where it really matters whether you use i386 or x86_64. The user *wants* to run the i386 bins. > On the filesystem people really want multilib, not multibin or > multiarch you are proposing. It works in multiple OSes and has been > in use for years (Irix, Solaris, Linux). I doubt people even really want multilib, you have two kind of people: o users that don't care at all about i386 and if they weren't forced to they wouldn't have a single i386 package on their x86_64 system. o developers/testers that "abuse" x86_64 arch for developing and testing i386 software on the same hardware. Up to the previous release we were focused on the first group only, and if we had continued we would had *decreased* (!) the numer of multilib packages, since some important ones finally made it to native x86_64. Instead we decided to support the second group as well introducing heuristics for "multilib development", which in reality should be transcriped as "too lazy to use a real i386 environment and be that in a chroot". Well, for whatever reason, we support that model, and then developers and testers need a place to actually install their bits. We're looking away since they usually install under /usr/local/bin and happiliy overwrite their 64/32 bit mixed up bindir folder. But the more we support this model the uglier it gets: It is far more easier to ship two pkgconfigs, one in /usr/bin and one in /usr/bin64 that return appropriate infos for the subarchs, than to make pkgconfig multilib aware. Same for a gazillion other similar to-be-multilibed tools. And the recent perl.so crazyness. We just get deeper and deeper into multilib's inadequate frameworks for what we are targetting. Therefore we either o need to revisit the goals, e.g. realize that the multilib design was at best for the users that need runtime support, and then live with the bugs as up to FC5, or o admit to a larger target group, where users mix and match as they please for developing i386 under x86_64 w/o chroots and create a solid architecture which doesn't rely on packages punching holes into other packages. Currently we're targeting the latter user group with the former tools, that's what's creating the pain. -- 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 Thu Apr 26 09:27:00 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 26 Apr 2007 11:27:00 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426092101.GE23704@neu.nirvana> References: <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> Message-ID: <1177579621.30803.579.camel@mccallum.corsepiu.local> On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote: > On Thu, Apr 26, 2007 at 09:56:33AM +0100, David Woodhouse wrote: > > On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > > > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > > > vs simply defining a new _bindir ...] > > > > > > Yes, but it does involve much more work to do. > > > > > > > > Packaging is hard. Let's go shopping. > > > > > > No, the above is not hard to do, it is a straightforward thing to do > > > that will occupy a full or more than one release cycle(s). > > > > > > I prefer to get F8 with some new features as well and not only a mass > > > review again. Which wil involve thre times as many packages as the FC > > > merge review which we didn't manage to finish. > > > > Actually, this one should be quite easy to automate. > > > > We've spent too long trying to take short-cuts and do the easiest thing > > in the _short_ term for multilib -- and it shows. It's time to start > > doing it properly, IMHBCO. > > Exactly and the proper thing for multilib is: Let it die, multiarch rulez! Apparently you haven't understood what multilibs are. Ralf From rc040203 at freenet.de Thu Apr 26 09:25:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 26 Apr 2007 11:25:12 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177577793.2755.303.camel@pmac.infradead.org> References: <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> Message-ID: <1177579512.30803.576.camel@mccallum.corsepiu.local> On Thu, 2007-04-26 at 09:56 +0100, David Woodhouse wrote: > On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > > vs simply defining a new _bindir ...] > > > RPM shouldn't be making those decisions. > > > > Indeed. > > > > > It should just be installing what it's told to, and it shouldn't be > > > told to install stuff which conflicts. > > > > Agreed. But in your proposal of splitting out all bin parts, the bin > > parts would still conflict, so no /usr/bin/firefox and no > > /usr/bin64/firefox. > > That's true (well, actually not for firefox right now but we plan to fix > that and eliminate the shell script in /usr/bin). But that's because > we've never really had 'coinstall _binaries_ of both architectures' as a > goal of our multilib support. It's multilib, not multibin. > > Multilib is about coinstalling libraries for both runtime and > development purposes -- but not binaries. Exactly. Multilibs are about * opening developers (note the "libs" in the name) opportunities to build for different architectures. An aspect that has widely been ignored by RH/Fedora, so far. E.g. to build x86_64 binaries on "i386" (Note: This is not reversed!), an aspect that has widely been ignored by RH/Fedora, so far. * To allow distributors/vendors to ship binaries of "run-time-compatible" architectures for architectures not being supported on particular architectures. The traditional approach (Sparc Solaris had multilibs ca a decade ago) to this had been to not to mix architectures, like Fedora/RH currently do, but to ship a nominal set of applications from mixed architectures, and to install their run-time dependencies (libraries) in parallel. > That's a new requirement, and > not something we've ever tried before. Except for testing purposes, I don't see much sense in this. Ordinary user want "firefox" and don't care about its architecture. But even for those (IMO, very rare occasions. firefox could be one of these), packagers could always resort to renaming the binaries (libs should not be affected because they already must not conflict in a multi-arched run-time environment). > I don't think we can manage it within the scope of the LSB. However, we > _can_ let the user choose which binary is installed in /usr/bin. And > perhaps we can let them install the other one with --relocate? > > Do we really want to let them install both? No, not wrt. %{_bindir} and /sbin. Ralf From Axel.Thimm at ATrpms.net Thu Apr 26 11:41:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 13:41:18 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <4630856D.8070908@leemhuis.info> References: <20070423200300.GB2874@free.fr> <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070426102140.GI355@devserv.devel.redhat.com> <4630856D.8070908@leemhuis.info> Message-ID: <20070426114118.GL23704@neu.nirvana> On Thu, Apr 26, 2007 at 12:56:45PM +0200, Thorsten Leemhuis wrote: > But doing something big like that only in Fedora seem utterly wrong to > me and makes us to much "special" and different from others. If > something like that really is wanted it IMHO should be done in > cooperation with other distros and/or the LSB, as changes like > {/usr,}/{s,}bin64 breaks a lot of expectations and requirements people, > apps and scripts currently have. Sure, but before contacting these groups, we need to know whether *we* want this model. This has been discussed "upstream" in the multilib/multiarch proposals (and even as recently as at the fosdem) and the consensus is that the current interested parties did not have the demand, yet, but if the demand comes up they will be open to it. So it will not come as a surprise if we ask the FHS to discuss for the next draft (which is happening now!) to allow for bin64. -- 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 chitlesh at fedoraproject.org Thu Apr 26 11:46:06 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 26 Apr 2007 13:46:06 +0200 Subject: buildsys: Error: could not make srpm In-Reply-To: <20070426125549.8b768456.bugs.michael@gmx.net> References: <13dbfe4f0704260245k46883e99sa05fe28ec44e2d9d@mail.gmail.com> <20070426125549.8b768456.bugs.michael@gmx.net> Message-ID: <13dbfe4f0704260446u71d08531wddb6dc85d01bd833@mail.gmail.com> On 4/26/07, Michael Schwendt wrote: > Does a manual upload with "make new-sources FILES=ktechlab-0.3.6.tar.bz2" > work for you? No it doesn't chitlesh(FC-5)[0]$make new-sources FILES=ktechlab-0.3.6.tar.bz2 Downloading ktechlab-0.3.6.tar.bz2... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 curl: (22) The requested URL returned error: 404 make: *** [ktechlab-0.3.6.tar.bz2] Error 22 chitlesh(FC-5)[0]$make new-sources FILES=../../rpmbuild/SOURCES/ktechlab-0.3.6.tar.bz2 Checking : ktechlab-0.3.6.tar.bz2 on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-sources] Error 255 chitlesh -- http://clunixchit.blogspot.com From Axel.Thimm at ATrpms.net Thu Apr 26 11:50:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 13:50:46 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177579621.30803.579.camel@mccallum.corsepiu.local> References: <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177579621.30803.579.camel@mccallum.corsepiu.local> Message-ID: <20070426115046.GM23704@neu.nirvana> On Thu, Apr 26, 2007 at 11:27:00AM +0200, Ralf Corsepius wrote: > On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote: > > On Thu, Apr 26, 2007 at 09:56:33AM +0100, David Woodhouse wrote: > > > On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > > > > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > > > > vs simply defining a new _bindir ...] > > > > > > > Yes, but it does involve much more work to do. > > > > > > > > > > Packaging is hard. Let's go shopping. > > > > > > > > No, the above is not hard to do, it is a straightforward thing to do > > > > that will occupy a full or more than one release cycle(s). > > > > > > > > I prefer to get F8 with some new features as well and not only a mass > > > > review again. Which wil involve thre times as many packages as the FC > > > > merge review which we didn't manage to finish. > > > > > > Actually, this one should be quite easy to automate. > > > > > > We've spent too long trying to take short-cuts and do the easiest thing > > > in the _short_ term for multilib -- and it shows. It's time to start > > > doing it properly, IMHBCO. > > > > Exactly and the proper thing for multilib is: Let it die, multiarch rulez! > > Apparently you haven't understood what multilibs are. Obviously your personal definition of multilib includes cross-compiling for x86_64 on i386. But we call multilib something else here, please adjust. -- 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 dwmw2 at infradead.org Thu Apr 26 12:07:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Apr 2007 13:07:43 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426111325.GH23704@neu.nirvana> References: <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> Message-ID: <1177589263.2755.365.camel@pmac.infradead.org> On Thu, 2007-04-26 at 13:13 +0200, Axel Thimm wrote: > Which is only needed once you start allowing (in your concept) files > of one "color" to be overwritable by another. Allowing that was always a mistake. It needs to die. > > 'punched install/remove holes'? > > See a prvious mail, but for the sake of context: > > yum install foo.i386 > yum install foo.x86_64 Error. Files from foo.x86_64 conflict with files from foo.i386. > yum remove foo.x86_64 Error. foo.x86_64 is not installed. > rpm -V foo Works fine. > > I'm listening.... be specific. How does it work? > > -%_bindir %{_exec_prefix}/bin > -%_sbindir %{_exec_prefix}/sbin > -%_libexecdir %{_exec_prefix}/libexec > +%_bindir %{_exec_prefix}/bin64 > +%_sbindir %{_exec_prefix}/sbin64 > +%_libexecdir %{_exec_prefix}/%{_lib} > > And sure, there will be packages with hardcoded bindirs to /usr/bin, > which we'll automatically detect on the first rebuild. And all binaries are built with matching rpath? And to look in %{_exec_prefix}/%{_lib} for dlopen, etc.? -- dwmw2 From fedora at leemhuis.info Thu Apr 26 12:17:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Apr 2007 14:17:02 +0200 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: <1177541584.17572.3.camel@lincoln> References: <1177541584.17572.3.camel@lincoln> Message-ID: <4630983E.50400@leemhuis.info> Brian Pepple schrieb: > > You want something to be discussed? [...] What about the "make the interaction between groups like FPC and EPEL on one side and FESCo on the other a bit easier" stuf. We discussed it a minute or two in the last meeting and on the list last week: https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00372.html There is a rough text in that mail that might be a good start -- but I suppose a native English speaker might be able to say it more clearer in less words.... Seems the PC discussed something like this in its meeting this week, too: https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00507.html CU thl From katzj at redhat.com Thu Apr 26 12:40:19 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 26 Apr 2007 08:40:19 -0400 Subject: Plan for tomorrows (20070426) FESCO meeting In-Reply-To: References: <1177541584.17572.3.camel@lincoln> <20070426102003.GI5296@free.fr> Message-ID: <1177591219.22739.25.camel@aglarond.local> On Thu, 2007-04-26 at 12:37 +0200, KH KH wrote: > I would like to ask which is the current status of firmware > distribution (Wifi) > I don't know for example if iwlwifi-firmware will be bundled, so > laptops with ipw3945 chipset could work "out of the box" (depending on > status with the last kernel) > > In such case: it would be good to bundle also zd1211-firmware, > which have been reported to work fine... Short answer: ipw2100, ipw2200, iwlwifi and zd1211 firmware are currently included in the default install. Answer on getting the answer: Check out comps[1] and look in the hardware-support group (as that's where firmware packages are being put). If the package is marked as default, then it'll get installed by default. The hardware-support group is installed by default on both regular installs and included on the live images.[2] > Other Ralink firmware status is unknow for now ... > (still in review process - but upstream do not bundle any license with > it) Given the freeze status, we're unlikely to add more firmwares to the default install of F7 before the release. Because by doing so, we're basically adding a feature and letting a driver do something... which then increases the chances for a driver blowing up on people. Jeremy [1] cvs -d:ext:cvs.fedoraproject.org:/cvs/extras co comps, see comps-f7.xml.in [2] The default and mandatory packages that is; optional packages are just that, optionally installed From jasperhartline at adelphia.net Thu Apr 26 12:42:29 2007 From: jasperhartline at adelphia.net (Jasper Hartline) Date: Thu, 26 Apr 2007 07:42:29 -0500 Subject: Problem with plague-client Message-ID: <46309E35.6060200@adelphia.net> Hello. I am Jasper Hartline (autopsy) and am currently in cvsdevel and cvextras groups with the FAS (Fedora Accounting System). When I follow the instructions here: http://fedoraproject.org/wiki/PackageMaintainers/BuildSystemClientSetup I get this error when running plague-client list: [autopsy at localhost ~]$ plague-client list Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in ? cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 85, in __init__ self._check_api_version(self._server) File "/usr/bin/plague-client", line 90, in _check_api_version server_ver = server.api_version() File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib/python2.4/xmlrpclib.py", line 1129, in request self.send_content(h, request_body) File "/usr/lib/python2.4/xmlrpclib.py", line 1243, in send_content connection.endheaders() File "/usr/lib/python2.4/httplib.py", line 798, in endheaders self._send_output() File "/usr/lib/python2.4/httplib.py", line 679, in _send_output self.send(msg) File "/usr/lib/python2.4/httplib.py", line 658, in send self.sock.sendall(str) File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line 110, in sendall sent = con.send(data, flags) OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] [autopsy at localhost ~]$ vi ~/.plague-client.cfg [autopsy at localhost ~]$ plague-client list_builders Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in ? cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 85, in __init__ self._check_api_version(self._server) File "/usr/bin/plague-client", line 90, in _check_api_version server_ver = server.api_version() File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib/python2.4/xmlrpclib.py", line 1129, in request self.send_content(h, request_body) File "/usr/lib/python2.4/xmlrpclib.py", line 1243, in send_content connection.endheaders() File "/usr/lib/python2.4/httplib.py", line 798, in endheaders self._send_output() File "/usr/lib/python2.4/httplib.py", line 679, in _send_output self.send(msg) File "/usr/lib/python2.4/httplib.py", line 658, in send self.sock.sendall(str) File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line 110, in sendall sent = con.send(data, flags) OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] [autopsy at localhost ~]$ Is there anyone who can verify that I am doing something wrong, or spot a problem with the instructions and let me know what to do? Thanks. J. Hartline (autopsy) From mmcgrath at redhat.com Thu Apr 26 13:48:30 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 26 Apr 2007 08:48:30 -0500 Subject: Problem with plague-client In-Reply-To: <46309E35.6060200@adelphia.net> References: <46309E35.6060200@adelphia.net> Message-ID: <4630ADAE.3040403@redhat.com> Jasper Hartline wrote: > OpenSSL.SSL.Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert > certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] grep After ~/.fedora.cert -Mike From mmcgrath at redhat.com Thu Apr 26 13:53:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 26 Apr 2007 08:53:06 -0500 Subject: buildsys: Error: could not make srpm In-Reply-To: <13dbfe4f0704260446u71d08531wddb6dc85d01bd833@mail.gmail.com> References: <13dbfe4f0704260245k46883e99sa05fe28ec44e2d9d@mail.gmail.com> <20070426125549.8b768456.bugs.michael@gmx.net> <13dbfe4f0704260446u71d08531wddb6dc85d01bd833@mail.gmail.com> Message-ID: <4630AEC2.30009@redhat.com> Chitlesh GOORAH wrote: > On 4/26/07, Michael Schwendt wrote: >> Does a manual upload with "make new-sources >> FILES=ktechlab-0.3.6.tar.bz2" >> work for you? > > No it doesn't > chitlesh(FC-5)[0]$make new-sources FILES=ktechlab-0.3.6.tar.bz2 > Downloading ktechlab-0.3.6.tar.bz2... > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left > Speed > 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 > --:--:-- 0 > curl: (22) The requested URL returned error: 404 > make: *** [ktechlab-0.3.6.tar.bz2] Error 22 > > chitlesh(FC-5)[0]$make new-sources > FILES=../../rpmbuild/SOURCES/ktechlab-0.3.6.tar.bz2 > > Checking : ktechlab-0.3.6.tar.bz2 on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [new-sources] Error 255 I can verify the file does not exist though I'm unsure why make new-sources is attempting to download that file. Just for kicks can you delete your local ktechlab and try checking out and doing another make new-sources FILES= -Mike From ralf.corsepius at rtems.org Thu Apr 26 13:12:17 2007 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Thu, 26 Apr 2007 15:12:17 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426115046.GM23704@neu.nirvana> References: <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177579621.30803.579.camel@mccallum.corsepiu.local> <20070426115046.GM23704@neu.nirvana> Message-ID: <1177593137.30803.652.camel@mccallum.corsepiu.local> On Thu, 2007-04-26 at 13:50 +0200, Axel Thimm wrote: > On Thu, Apr 26, 2007 at 11:27:00AM +0200, Ralf Corsepius wrote: > > On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote: > > > On Thu, Apr 26, 2007 at 09:56:33AM +0100, David Woodhouse wrote: > > > > On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > > > > > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > > > > > vs simply defining a new _bindir ...] > > > > > > > > Yes, but it does involve much more work to do. > > > > > > > > > > > > Packaging is hard. Let's go shopping. > > > > > > > > > > No, the above is not hard to do, it is a straightforward thing to do > > > > > that will occupy a full or more than one release cycle(s). > > > > > > > > > > I prefer to get F8 with some new features as well and not only a mass > > > > > review again. Which wil involve thre times as many packages as the FC > > > > > merge review which we didn't manage to finish. > > > > > > > > Actually, this one should be quite easy to automate. > > > > > > > > We've spent too long trying to take short-cuts and do the easiest thing > > > > in the _short_ term for multilib -- and it shows. It's time to start > > > > doing it properly, IMHBCO. > > > > > > Exactly and the proper thing for multilib is: Let it die, multiarch rulez! > > > > Apparently you haven't understood what multilibs are. > > Obviously your personal definition of multilib includes > cross-compiling for x86_64 on i386. Yes, because THIS is multilib'ing. > But we call multilib something > else here, please adjust. The concept of multilibs as being defined by GCC exists for than a decade (More precisely: <= 1995). What you are naming multilibs is mixing architectures at run-time. The correct term for this would be multi-arch'ing or bi-arch'ing as far as the ix86 family is concerned. Multilibs can be applied to implement multi-arch'ing, but actually multi-arching isn't tied to multilibs at all. Ralf From rnorwood at redhat.com Thu Apr 26 15:13:59 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 26 Apr 2007 11:13:59 -0400 Subject: Spilt libperl from perl In-Reply-To: <1177583386.2755.340.camel@pmac.infradead.org> (David Woodhouse's message of "Thu, 26 Apr 2007 11:29:46 +0100") References: <462A6A23.5030409@redhat.com> <462D0666.2000201@redhat.com> <1177357164.5956.23.camel@localhost.localdomain> <1177583386.2755.340.camel@pmac.infradead.org> Message-ID: David Woodhouse writes: > On Mon, 2007-04-23 at 14:39 -0500, Tom "spot" Callaway wrote: >> I'm not going to support making a libperl subpackage to dodge fixing >> multilib. By doing this, we just slide down the slippery slope of >> avoiding the problem, and relying on dirty hacks instead of solving >> the hard problems. > > I believe you retracted this on IRC, after I pointed out that this is > actually the _fix_ to avoid the dirty hack in RPM which allows the > installation of conflicting files. > > You said we'd go ahead and split the package. But it doesn't seem to > have been done yet -- are we still going ahead with it? I have the split in CVS - I'm waiting for Tom to have a chance to review it before I do a real build. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From ed at eh3.com Thu Apr 26 15:52:03 2007 From: ed at eh3.com (Ed Hill) Date: Thu, 26 Apr 2007 11:52:03 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426081658.GC23704@neu.nirvana> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> Message-ID: <20070426115203.630dd309@daggett> On Thu, 26 Apr 2007 10:16:58 +0200 Axel Thimm wrote: > > On Thu, Apr 26, 2007 at 09:29:23AM +0200, Patrice Dumas wrote: > > > > But it will end up, on x86_64 with the binaries for the primary > > arch not to be in the classical paths. Wouldn't it better to have > > _bindir=/usr/bin32 for 32 bit apps? > > No, because you want to reuse the packages from i386 that will already > occupy /usr/bin. /usr/bin32 for i386 would imply that > > o either all packages in i386 are rebuilt for i386 to place their bins > there, too, and then your argument of not a classical path would > apply to all i386 system, which outweigh the x86_64 ones, or > > o You have different i386 packages for i386 and x86_64, which is also > not a good solution, because you lose the QA for the pure i386 > packages. Well put! I would like to see Fedora adopt the {,/usr}/{,s}bin64 handling as described by Axel. Or something very similar to it. If it is possible (and I think it is), I'd like to have a framework that allows *full* co-existence of 32-bit and 64-bit packages. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sheltren at cs.ucsb.edu Thu Apr 26 16:00:54 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 26 Apr 2007 09:00:54 -0700 Subject: buildsys: Error: could not make srpm In-Reply-To: <4630AEC2.30009@redhat.com> References: <13dbfe4f0704260245k46883e99sa05fe28ec44e2d9d@mail.gmail.com> <20070426125549.8b768456.bugs.michael@gmx.net> <13dbfe4f0704260446u71d08531wddb6dc85d01bd833@mail.gmail.com> <4630AEC2.30009@redhat.com> Message-ID: <8056FB19-A418-4E50-B371-374D4BD304F0@cs.ucsb.edu> On Apr 26, 2007, at 6:53 AM, Mike McGrath wrote: > > I can verify the file does not exist though I'm unsure why make new- > sources is attempting to download that file. Just for kicks can > you delete your local ktechlab and try checking out and doing > another make new-sources FILES= > > -Mike Hi Mike, it seems that the upload script first wants to check the destination file (since it thinks it should exist already). Is it possible for you to touch that file so that it exists? That should allow the file upload to succeed when Chitlesh does a 'make new- souces'... -Jeff From jkeating at redhat.com Thu Apr 26 16:07:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Apr 2007 12:07:56 -0400 Subject: F7 Test4 freeze over, continued devel freeze. Message-ID: <200704261207.56702.jkeating@redhat.com> We've released F7 Test4, and as such we're not frozen for Test4, however we're in continual freeze for the final, only excepting bugfixes. A tag exists (f7-final) that rawhide and the final release will use. If your Core build is not tagged for f7-final, it will not be seen as devel/ builds go to dist-fc7. See http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy for policy. Again, this only effects Core packages. We ask you to have consideration with Extras packages as well, not introducing disruptive changes if at all possible. -- 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 chitlesh at fedoraproject.org Thu Apr 26 16:25:13 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 26 Apr 2007 18:25:13 +0200 Subject: buildsys: Error: could not make srpm In-Reply-To: <8056FB19-A418-4E50-B371-374D4BD304F0@cs.ucsb.edu> References: <13dbfe4f0704260245k46883e99sa05fe28ec44e2d9d@mail.gmail.com> <20070426125549.8b768456.bugs.michael@gmx.net> <13dbfe4f0704260446u71d08531wddb6dc85d01bd833@mail.gmail.com> <4630AEC2.30009@redhat.com> <8056FB19-A418-4E50-B371-374D4BD304F0@cs.ucsb.edu> Message-ID: <13dbfe4f0704260925y3d26d831t1a2ce36123767395@mail.gmail.com> On 4/26/07, Jeff Sheltren wrote: > Hi Mike, it seems that the upload script first wants to check the > destination file (since it thinks it should exist already). Is it > possible for you to touch that file so that it exists? That should > allow the file upload to succeed when Chitlesh does a 'make new- > souces'... Thanks, I've caught Mike on irc, and somehow when -I cleaned the local ktechlab directory and checkout again. -Then committed the source tarball separately thanks for your help, Chitlesh -- http://clunixchit.blogspot.com From Axel.Thimm at ATrpms.net Thu Apr 26 17:13:22 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 19:13:22 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177593137.30803.652.camel@mccallum.corsepiu.local> References: <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177579621.30803.579.camel@mccallum.corsepiu.local> <20070426115046.GM23704@neu.nirvana> <1177593137.30803.652.camel@mccallum.corsepiu.local> Message-ID: <20070426171322.GA7127@neu.nirvana> On Thu, Apr 26, 2007 at 03:12:17PM +0200, Ralf Corsepius wrote: > On Thu, 2007-04-26 at 13:50 +0200, Axel Thimm wrote: > > On Thu, Apr 26, 2007 at 11:27:00AM +0200, Ralf Corsepius wrote: > > > On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote: > > > > On Thu, Apr 26, 2007 at 09:56:33AM +0100, David Woodhouse wrote: > > > > > On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > > > > > > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > > > > > > vs simply defining a new _bindir ...] > > > > > > > > > Yes, but it does involve much more work to do. > > > > > > > > > > > > > > Packaging is hard. Let's go shopping. > > > > > > > > > > > > No, the above is not hard to do, it is a straightforward thing to do > > > > > > that will occupy a full or more than one release cycle(s). > > > > > > > > > > > > I prefer to get F8 with some new features as well and not only a mass > > > > > > review again. Which wil involve thre times as many packages as the FC > > > > > > merge review which we didn't manage to finish. > > > > > > > > > > Actually, this one should be quite easy to automate. > > > > > > > > > > We've spent too long trying to take short-cuts and do the easiest thing > > > > > in the _short_ term for multilib -- and it shows. It's time to start > > > > > doing it properly, IMHBCO. > > > > > > > > Exactly and the proper thing for multilib is: Let it die, multiarch rulez! > > > > > > Apparently you haven't understood what multilibs are. > > > > Obviously your personal definition of multilib includes > > cross-compiling for x86_64 on i386. > Yes, because THIS is multilib'ing. > > > But we call multilib something else here, please adjust. > > The concept of multilibs as being defined by GCC exists for than a > decade (More precisely: <= 1995). > > What you are naming multilibs is mixing architectures at run-time. > The correct term for this would be multi-arch'ing or bi-arch'ing as far > as the ix86 family is concerned. > > Multilibs can be applied to implement multi-arch'ing, but actually > multi-arching isn't tied to multilibs at all. OK, so we agree, we have a different definition of multilib than you do. since all on this list use multilib in the "mixing arch" version of the definition, please adjust, otherwise you only confuse us. :) I'm sure both you and we understand both uses of multilib. And even if you don't agree to our usage maybe you can comment more on the technical parts than whether the given name is appropriate or not. -- 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 Thu Apr 26 17:16:48 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 19:16:48 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177589263.2755.365.camel@pmac.infradead.org> References: <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> Message-ID: <20070426171648.GB7127@neu.nirvana> On Thu, Apr 26, 2007 at 01:07:43PM +0100, David Woodhouse wrote: > On Thu, 2007-04-26 at 13:13 +0200, Axel Thimm wrote: > > Which is only needed once you start allowing (in your concept) files > > of one "color" to be overwritable by another. > > Allowing that was always a mistake. It needs to die. > > > > 'punched install/remove holes'? > > > > See a prvious mail, but for the sake of context: > > > > yum install foo.i386 > > yum install foo.x86_64 > > Error. Files from foo.x86_64 conflict with files from foo.i386. > > > yum remove foo.x86_64 > > Error. foo.x86_64 is not installed. > > > rpm -V foo > > Works fine. God, I hate it when people trim away the important parts. Aow you assume again your model of "review everything once again, we'll split off all bins by F10-F11", but I'm still in this year, and want Fedora to do something more then rereviewing all its specfiles several times a year. > > > I'm listening.... be specific. How does it work? > > > > -%_bindir %{_exec_prefix}/bin > > -%_sbindir %{_exec_prefix}/sbin > > -%_libexecdir %{_exec_prefix}/libexec > > +%_bindir %{_exec_prefix}/bin64 > > +%_sbindir %{_exec_prefix}/sbin64 > > +%_libexecdir %{_exec_prefix}/%{_lib} > > > > And sure, there will be packages with hardcoded bindirs to /usr/bin, > > which we'll automatically detect on the first rebuild. > > And all binaries are built with matching rpath? And to look in > %{_exec_prefix}/%{_lib} for dlopen, etc.? I don't see why not, but I also don't see what it buy us. -- 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 Thu Apr 26 17:18:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 19:18:47 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426171648.GB7127@neu.nirvana> References: <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> Message-ID: <20070426171847.GC7127@neu.nirvana> On Thu, Apr 26, 2007 at 07:16:48PM +0200, Axel Thimm wrote: > > > > I'm listening.... be specific. How does it work? > > > > > > -%_bindir %{_exec_prefix}/bin > > > -%_sbindir %{_exec_prefix}/sbin > > > -%_libexecdir %{_exec_prefix}/libexec > > > +%_bindir %{_exec_prefix}/bin64 > > > +%_sbindir %{_exec_prefix}/sbin64 > > > +%_libexecdir %{_exec_prefix}/%{_lib} > > > > > > And sure, there will be packages with hardcoded bindirs to /usr/bin, > > > which we'll automatically detect on the first rebuild. > > > > And all binaries are built with matching rpath? And to look in > > %{_exec_prefix}/%{_lib} for dlopen, etc.? > > I don't see why not, but I also don't see what it buy us. Why would moving bindir have any effect on rpaths to any of the libdirs? I think these are rather orthogonal issues. -- 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 26 17:22:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Apr 2007 13:22:00 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a Message-ID: <200704261322.01077.jkeating@redhat.com> Fill in your suggestion for the blanks. Cannot link to Zod in the same way that Zod is linked to Bordeaux. Suggestions will be ran through the legal queue and an election will happen for Fedora contributors to pick the next Fedora name. -- 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 notting at redhat.com Thu Apr 26 17:25:14 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Apr 2007 13:25:14 -0400 Subject: request for comaintainers Message-ID: <20070426172514.GA3756@nostromo.devel.redhat.com> I'm looking for co-maintainers of a few of my packages: - gnucash - aqbanking - gwenhywfar - perl-Finance-Quote - perl-HTML-TableExtract Special extra bonus points for someone who actually has various accounts to test online banking stuff in aqbanking, especially the HBCI code for German banks, as it's more or less included 'as-is, hope it works for you!'. Bill From chris.stone at gmail.com Thu Apr 26 17:33:46 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Thu, 26 Apr 2007 10:33:46 -0700 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070426114118.GL23704@neu.nirvana> References: <20070423200300.GB2874@free.fr> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070426102140.GI355@devserv.devel.redhat.com> <4630856D.8070908@leemhuis.info> <20070426114118.GL23704@neu.nirvana> Message-ID: Why can't we have lib32 and bin32 instead? Aren't 32bit CPUs dead yet?? From notting at redhat.com Thu Apr 26 17:44:21 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Apr 2007 13:44:21 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261322.01077.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> Message-ID: <20070426174421.GB3756@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > Fill in your suggestion for the blanks. Cannot link to Zod in the > same way that Zod is linked to Bordeaux. > > Suggestions will be ran through the legal queue and an election will happen > for Fedora contributors to pick the next Fedora name. Bordeaux -> Zod was DC universe characters. Which pretty much takes out all the direct Superman references. So, other things. Zod is: - a character played by Terence Stamp - he's played other characters named 'Fish', 'Stick', 'Siegfried', 'The Limey' - a General - Sherman, Patton, Hannibal, Lee, Orlov, Grevious, and many many many many others Bill From jkeating at redhat.com Thu Apr 26 17:48:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Apr 2007 13:48:10 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <20070426174421.GB3756@nostromo.devel.redhat.com> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> Message-ID: <200704261348.10615.jkeating@redhat.com> On Thursday 26 April 2007 13:44:21 Bill Nottingham wrote: > Hannibal Oh man, I like this one. F9 could be another famous cannibal? -- 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 limb at jcomserv.net Thu Apr 26 17:49:16 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 26 Apr 2007 12:49:16 -0500 (CDT) Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <20070426174421.GB3756@nostromo.devel.redhat.com> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> Message-ID: <32922.65.192.24.190.1177609756.squirrel@mail.jcomserv.net> Valorum? > Jesse Keating (jkeating at redhat.com) said: >> Fill in your suggestion for the blanks. Cannot link to Zod in >> the >> same way that Zod is linked to Bordeaux. >> >> Suggestions will be ran through the legal queue and an election will >> happen >> for Fedora contributors to pick the next Fedora name. > > Bordeaux -> Zod was DC universe characters. Which pretty much takes out > all the direct Superman references. > > So, other things. Zod is: > > - a character played by Terence Stamp > > - he's played other characters named 'Fish', 'Stick', 'Siegfried', > 'The Limey' > > - a General > > - Sherman, Patton, Hannibal, Lee, Orlov, Grevious, and many many many > many others > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From notting at redhat.com Thu Apr 26 18:01:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Apr 2007 14:01:51 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261348.10615.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> <200704261348.10615.jkeating@redhat.com> Message-ID: <20070426180151.GC3756@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > Hannibal > > Oh man, I like this one. F9 could be another famous cannibal? I love it when a plan comes together. Bill From ajackson at redhat.com Thu Apr 26 17:57:08 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 26 Apr 2007 13:57:08 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261322.01077.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> Message-ID: <1177610228.2745.21.camel@localhost.localdomain> On Thu, 2007-04-26 at 13:22 -0400, Jesse Keating wrote: > Fill in your suggestion for the blanks. Cannot link to Zod in the > same way that Zod is linked to Bordeaux. > > Suggestions will be ran through the legal queue and an election will happen > for Fedora contributors to pick the next Fedora name. Scorpio. Hank Scorpio in particular. Cartoon supervillians. - ajax From jkeating at redhat.com Thu Apr 26 18:20:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Apr 2007 14:20:40 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177610228.2745.21.camel@localhost.localdomain> References: <200704261322.01077.jkeating@redhat.com> <1177610228.2745.21.camel@localhost.localdomain> Message-ID: <200704261420.40331.jkeating@redhat.com> On Thursday 26 April 2007 13:57:08 Adam Jackson wrote: > Scorpio. ?Hank Scorpio in particular. ?Cartoon supervillians. I think that's a little too close to the Bordeaux -> Zod link. -- 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 skvidal at linux.duke.edu Thu Apr 26 18:32:08 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 26 Apr 2007 14:32:08 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <20070426180151.GC3756@nostromo.devel.redhat.com> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> <200704261348.10615.jkeating@redhat.com> <20070426180151.GC3756@nostromo.devel.redhat.com> Message-ID: <1177612328.14131.4.camel@cutter> On Thu, 2007-04-26 at 14:01 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > > Hannibal > > > > Oh man, I like this one. F9 could be another famous cannibal? > > I love it when a plan comes together. > that was so _wrong_. -sv From ajackson at redhat.com Thu Apr 26 18:07:11 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 26 Apr 2007 14:07:11 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261420.40331.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <1177610228.2745.21.camel@localhost.localdomain> <200704261420.40331.jkeating@redhat.com> Message-ID: <1177610831.2745.23.camel@localhost.localdomain> On Thu, 2007-04-26 at 14:20 -0400, Jesse Keating wrote: > On Thursday 26 April 2007 13:57:08 Adam Jackson wrote: > > Scorpio. Hank Scorpio in particular. Cartoon supervillians. > > I think that's a little too close to the Bordeaux -> Zod link. I think you're a big fat meanie head. - ajax From seg at haxxed.com Thu Apr 26 18:53:44 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 26 Apr 2007 13:53:44 -0500 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261322.01077.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> Message-ID: <1177613624.15366.52.camel@localhost.localdomain> On Thu, 2007-04-26 at 13:22 -0400, Jesse Keating wrote: > Fill in your suggestion for the blanks. Cannot link to Zod in the > same way that Zod is linked to Bordeaux. Zod is a General, and the core/extras merge is general chaos, so Fedora 7 = Chaos? Or maybe Ordo ab Chao. -------------- 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 icon at fedoraproject.org Thu Apr 26 18:55:20 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 26 Apr 2007 14:55:20 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261322.01077.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> Message-ID: On 4/26/07, Jesse Keating wrote: > Fill in your suggestion for the blanks. Cannot link to Zod in the > same way that Zod is linked to Bordeaux. > > Suggestions will be ran through the legal queue and an election will happen > for Fedora contributors to pick the next Fedora name. Let's go with villains. Hence... KHAAAAAAN! -- Konstantin Ryabitsev Montr?al, Qu?bec From caillon at redhat.com Thu Apr 26 19:00:14 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 26 Apr 2007 15:00:14 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261322.01077.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> Message-ID: <4630F6BE.9060507@redhat.com> Jesse Keating wrote: > Fill in your suggestion for the blanks. Cannot link to Zod in the > same way that Zod is linked to Bordeaux. > > Suggestions will be ran through the legal queue and an election will happen > for Fedora contributors to pick the next Fedora name. - Zod Records - This might be an interesting connection since FC7 is going to have support for the gstreamer-missing-codec stuff. Some random record companies whose names I didn't hate at a quick glance: 'Iron Fist' (also references Zod) 'Metropolis' (as does this) 'Hannibal' (also ties in as a General) 'Cleopatra' 'Cylon' 'Moonshine' 'Neptune' 'Pendragon' - Tapwave Zod - A rather shortlived gaming platform. The official name was the Zodiac, but it went by Zod for short (gaming geeks, go figure). - Names such as 'Genesis', 'Saturn', etc. might also be relevant. Apple's already got 'Jaguar' and we've got a program named 'Lynx'... From dwmw2 at infradead.org Thu Apr 26 19:00:21 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Apr 2007 20:00:21 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426171648.GB7127@neu.nirvana> References: <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> Message-ID: <1177614021.2755.430.camel@pmac.infradead.org> On Thu, 2007-04-26 at 19:16 +0200, Axel Thimm wrote: > God, I hate it when people trim away the important parts. Aow you > assume again your model of "review everything once again, we'll split > off all bins by F10-F11", but I'm still in this year, and want Fedora > to do something more then rereviewing all its specfiles several times > a year. Ah, I see. So for the sake of sanity, I shall just pretend that when I asked for clarification by quoting "punched install/remove holes?" when you claimed they were "firmly embedded in the multilib design", your response was as follows: -> > 'punched install/remove holes'? -> -> No, I misspoke. Those, along with the 'rpm special handling' of which -> I spoke, are not firmly embedded in the multilib design; they were -> just another problem created by another bad short-term decision, as -> you said. -- dwmw2 From buildsys at fedoraproject.org Thu Apr 26 19:06:53 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 Apr 2007 15:06:53 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-26 Message-ID: <20070426190653.8319B152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): m4 FC6-updates > FC7 (0:1.4.8-2 > 0:1.4.8-1) cbalint AT redhat.com: iverilog FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.4.7-5.fc5 > 0:0.4.6-0.fc6) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.4.7-5.fc5 > 0:0.4.6-0.fc6) dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) iverilog: cbalint AT redhat.com FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) m4: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.4.8-2 > 0:1.4.8-1) From seg at haxxed.com Thu Apr 26 19:10:37 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 26 Apr 2007 14:10:37 -0500 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177613624.15366.52.camel@localhost.localdomain> References: <200704261322.01077.jkeating@redhat.com> <1177613624.15366.52.camel@localhost.localdomain> Message-ID: <1177614637.15366.56.camel@localhost.localdomain> Fedora 7 (Ripper) As in, General Jack D. Ripper. -------------- 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 rdieter at math.unl.edu Thu Apr 26 19:18:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Apr 2007 14:18:47 -0500 Subject: request for comaintainers In-Reply-To: <20070426172514.GA3756@nostromo.devel.redhat.com> References: <20070426172514.GA3756@nostromo.devel.redhat.com> Message-ID: <4630FB17.80403@math.unl.edu> Bill Nottingham wrote: > I'm looking for co-maintainers of a few of my packages: > > - gnucash > - aqbanking count me interested in co-maintaining aqbanking. Likewise, I'd be happy to take on co-maintainers for - kmymoney2 also with bonus kudos for folks who can do online banking testing similar to gnucash. :) -- Rex From jspaleta at gmail.com Thu Apr 26 19:25:23 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 26 Apr 2007 11:25:23 -0800 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <20070426174421.GB3756@nostromo.devel.redhat.com> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> Message-ID: <604aa7910704261225v3c4d1fc8tc1a63d731d232a76@mail.gmail.com> On 4/26/07, Bill Nottingham wrote: > - a character played by Terence Stamp > > - he's played other characters named 'Fish', 'Stick', 'Siegfried', > 'The Limey' Man i totally didn't recognize him in The Limey. -jef"ugh he was in episode one of the star war too....that opens up a wealth of particularly bad names for f8"spaleta From lemenkov at gmail.com Thu Apr 26 19:28:43 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Thu, 26 Apr 2007 23:28:43 +0400 Subject: [Minimizing Fedora] Langpacks for Firefox. Message-ID: Hello All! I found another one thing that was made unpractically. We got langpacks for 40 different languages that occupies ~12 MBytes from 43 Mbytes. This situatuin is drastically dioffers fron one with OpenOffice.org whose langpacks are not shipped with main app. I think that it would be reasonable to split firefox into main application package and many language packs. -- With best regards! From Axel.Thimm at ATrpms.net Thu Apr 26 19:30:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 26 Apr 2007 21:30:41 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177614021.2755.430.camel@pmac.infradead.org> References: <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> Message-ID: <20070426193041.GB14127@neu.nirvana> On Thu, Apr 26, 2007 at 08:00:21PM +0100, David Woodhouse wrote: > On Thu, 2007-04-26 at 19:16 +0200, Axel Thimm wrote: > > God, I hate it when people trim away the important parts. Aow you > > assume again your model of "review everything once again, we'll split > > off all bins by F10-F11", but I'm still in this year, and want Fedora > > to do something more then rereviewing all its specfiles several times > > a year. > > Ah, I see. > > So for the sake of sanity, I shall just pretend that when I asked for > clarification by quoting "punched install/remove holes?" when you > claimed they were "firmly embedded in the multilib design", your > response was as follows: No, that was not my response, not even close. > -> > 'punched install/remove holes'? > -> > -> No, I misspoke. Those, along with the 'rpm special handling' of which > -> I spoke, are not firmly embedded in the multilib design; they were > -> just another problem created by another bad short-term decision, as > -> you said. multilib design (TM) is the (un)art of splitting only the libdir for archs and performing ugly hacks to cross-overwriting techniques. As such the punchhole remove/install problem is an embedded issue of the multilib design (TM). The "David Woodhouse improved multilib design that requires bin suppackage splits for every bin carrying package" tries to circumvent this problem by spliting out the bin contents in subpackages. But this is another bad short-term decision, as it o forces us to revisit every bin carrying package out there speding tons of resources better used elsewhere o still does not allow us to simply have two disting repos for both arch, since we would have to filter out all bin subpackages o If we don't filter then we just pass the problem to all depsolvers, e.g. yum, smart, apt In comparison the bin64 solution costs us almost nothing: o most packages will rebuild in unattended mode o breakage of false bindir will be detected during the build itself o You can use two cleanly distinct repos with the depsolver tools of today, no need to add any funny support anywhere o You fix an FHS violation, in exchange for another, which just brings us bad to balance o The FHS has already considered this (thanks to the Debain folks) and is waiting for distros to actually utter the demand to include it. So for the sake of sanity, I shall just pretend that when you read this you will answer: > Yes, I'm convinced, I didn't realize all that, go for it. Yeah, I know, probably not even close :) -- 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 Christian.Iseli at licr.org Thu Apr 26 20:02:50 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 26 Apr 2007 22:02:50 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426115203.630dd309@daggett> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> <20070426115203.630dd309@daggett> Message-ID: <20070426220250.39a9012c@ludwig-alpha.unil.ch> On Thu, 26 Apr 2007 11:52:03 -0400, Ed Hill wrote: > I would like to see Fedora adopt the {,/usr}/{,s}bin64 handling as > described by Axel. Or something very similar to it. > > If it is possible (and I think it is), I'd like to have a framework > that allows *full* co-existence of 32-bit and 64-bit packages. I'm pretty lost here... Why would anyone want a multiarch system ? I mean, we already have chroots and virtual machines, so what more does it buy us to get a big mess of duplicated things? I understand multilib a bit better. It can be useful when a particular tool (e.g. firefox and its plugins) work better on one arch than on the other one. But I just want one of them usually. I don't see how having a /bin/ls, a /bin32/ls and a /bin64/ls all at the same time is going to be useful. Of course, if I could have my druthers, then I'd prefer a fully working 64 bits firefox and plugins... hopefully some day... C From nphilipp at redhat.com Thu Apr 26 20:21:12 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 26 Apr 2007 22:21:12 +0200 Subject: F7 Test4 freeze over, continued devel freeze. In-Reply-To: <200704261207.56702.jkeating@redhat.com> References: <200704261207.56702.jkeating@redhat.com> Message-ID: <1177618873.11826.5.camel@gibraltar.stuttgart.redhat.com> Hey Jesse, On Thu, 2007-04-26 at 12:07 -0400, Jesse Keating wrote: > We've released F7 Test4, and as such we're not frozen for Test4, however we're > in continual freeze for the final, only excepting bugfixes. A tag exists > (f7-final) that rawhide and the final release will use. If your Core build > is not tagged for f7-final, it will not be seen as devel/ builds go to > dist-fc7. excuse my ignorance ;-), but exactly what are we supposed to do to get packages built a) between test 4 freeze and now and b) from now on? Is "make COLLECTION=dist-fc7-final build" sufficient? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Thu Apr 26 20:23:48 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 26 Apr 2007 22:23:48 +0200 Subject: F7 Test4 freeze over, continued devel freeze. In-Reply-To: <1177618873.11826.5.camel@gibraltar.stuttgart.redhat.com> References: <200704261207.56702.jkeating@redhat.com> <1177618873.11826.5.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1177619028.11826.8.camel@gibraltar.stuttgart.redhat.com> On Thu, 2007-04-26 at 22:21 +0200, Nils Philippsen wrote: > Hey Jesse, > > On Thu, 2007-04-26 at 12:07 -0400, Jesse Keating wrote: > > We've released F7 Test4, and as such we're not frozen for Test4, however we're > > in continual freeze for the final, only excepting bugfixes. A tag exists > > (f7-final) that rawhide and the final release will use. If your Core build > > is not tagged for f7-final, it will not be seen as devel/ builds go to > > dist-fc7. > > excuse my ignorance ;-), but exactly what are we supposed to do to get > packages built a) between test 4 freeze and now and b) from now on? Is > "make COLLECTION=dist-fc7-final build" sufficient? Well that may be sufficient for newly built packages, but moving the packages over from dist-fc7 to dist-fc7-final surely works differently, right? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From Jochen at herr-schmitt.de Thu Apr 26 20:49:26 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 26 Apr 2007 22:49:26 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: References: Message-ID: <46311056.8040004@herr-schmitt.de> Peter Lemenkov schrieb: > I think that it would be reasonable to split firefox into main > application package and many language packs. I agree with you, There should be the following packages: firefox (The main package) firefox-devel (Package for development) firefox-langpack-xx (Language-Pack) Even if this may be too late for FC7, you should create a bugzilla request for the responsible maintainers of firefox. If you may do this, you may create a ticket for thunderbird too, becouse there you have the same situation. Perhaps we should add a paragraph to the packaging guidelines about this topic. Best Regards: Jochen Schmitt From bnocera at redhat.com Thu Apr 26 20:59:44 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 26 Apr 2007 21:59:44 +0100 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <20070426174421.GB3756@nostromo.devel.redhat.com> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> Message-ID: <1177621184.23975.64.camel@cookie.hadess.net> On Thu, 2007-04-26 at 13:44 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > Fill in your suggestion for the blanks. Cannot link to Zod in the > > same way that Zod is linked to Bordeaux. > > > > Suggestions will be ran through the legal queue and an election will happen > > for Fedora contributors to pick the next Fedora name. > > Bordeaux -> Zod was DC universe characters. Which pretty much takes out > all the direct Superman references. > > So, other things. Zod is: > > - a character played by Terence Stamp > > - he's played other characters named 'Fish', 'Stick', 'Siegfried', > 'The Limey' > > - a General > > - Sherman, Patton, Hannibal, Lee, Orlov, Grevious, and many many many > many others When playing Zod, he was released by Kal-el, which is also the name of Nicholas Cage's son. Then open up a Copolla, Spielberg connection. Sloth. Nevermind, Zod is a book[1], so is Sloth[2]. Then I can get some monster connections. [1]: http://www.amazon.com/Zod-Fritz-Vongucci/dp/1401095143 [2]: http://www.amazon.com/Sloth-Gilbert-Hernandez/dp/1401203663/ From caillon at redhat.com Thu Apr 26 21:11:33 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 26 Apr 2007 17:11:33 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: References: Message-ID: <46311585.20204@redhat.com> Peter Lemenkov wrote: > Hello All! > I found another one thing that was made unpractically. We got > langpacks for 40 different languages that occupies ~12 MBytes from 43 > Mbytes. This situatuin is drastically dioffers fron one with > OpenOffice.org whose langpacks are not shipped with main app. > > I think that it would be reasonable to split firefox into main > application package and many language packs. On my system right now, /usr/share/locale takes up 373MB, dwarfing whatever Firefox uses. Splitting out Firefox's langpacks won't solve your problem. From dwmw2 at infradead.org Thu Apr 26 21:39:23 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 26 Apr 2007 22:39:23 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426193041.GB14127@neu.nirvana> References: <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> Message-ID: <1177623564.2755.461.camel@pmac.infradead.org> On Thu, 2007-04-26 at 21:30 +0200, Axel Thimm wrote: > multilib design (TM) is the (un)art of splitting only the libdir for > archs and performing ugly hacks to cross-overwriting techniques. It's the art of splitting the libdir. The ugly hacks were an implementation detail which are largely unnecessary when you stop and actually think about it. > As such the punchhole remove/install problem is an embedded issue of > the multilib design (TM). Not at all. It's just an aspect of the dirty hack we put in RPM to allow conflicting binaries to be installed. Not a fundamental problem with multilib at all. > The "David Woodhouse improved multilib design that requires bin > suppackage splits for every bin carrying package" tries to circumvent > this problem by spliting out the bin contents in subpackages. But this > is another bad short-term decision, as it > > o forces us to revisit every bin carrying package out there speding > tons of resources better used elsewhere You overestimate the effort involved. It can be checked automatically, and when conflicts are found, the fix is simple. > o still does not allow us to simply have two disting repos for both > arch, since we would have to filter out all bin subpackages No, because you _want_ both sets of bin subpackages available. The user gets to install the secondary version _if_ they want it. > o If we don't filter then we just pass the problem to all depsolvers, > e.g. yum, smart, apt No, those just install the primary architecture. The secondary arch only ever gets installed if the user specifically asks for it. > In comparison the bin64 solution costs us almost nothing: > o most packages will rebuild in unattended mode > o breakage of false bindir will be detected during the build itself > o You can use two cleanly distinct repos with the depsolver tools of > today, no need to add any funny support anywhere > o You fix an FHS violation, in exchange for another, which just brings > us bad to balance > o The FHS has already considered this (thanks to the Debain folks) and > is waiting for distros to actually utter the demand to include it. It buys you the ability to install _both_ versions of the package simultaneously, but you can't easily choose which version to prefer for a _specific_ package -- you can only set bin64 before or after bin in $PATH, which affects _all_ installed programs. Unless you split the packages out so that you can have libraries installed for the secondary arch without having to have the binaries, I suppose? :) -- dwmw2 From alan at redhat.com Thu Apr 26 21:52:51 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 26 Apr 2007 17:52:51 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <4630F6BE.9060507@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <4630F6BE.9060507@redhat.com> Message-ID: <20070426215251.GB18327@devserv.devel.redhat.com> On Thu, Apr 26, 2007 at 03:00:14PM -0400, Christopher Aillon wrote: > 'Metropolis' (as does this) > 'Hannibal' (also ties in as a General) > 'Pendragon' Works for me. Especially Metropolis From Axel.Thimm at ATrpms.net Fri Apr 27 00:26:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 02:26:08 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177623564.2755.461.camel@pmac.infradead.org> References: <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> Message-ID: <20070427002608.GC21691@neu.nirvana> On Thu, Apr 26, 2007 at 10:39:23PM +0100, David Woodhouse wrote: > On Thu, 2007-04-26 at 21:30 +0200, Axel Thimm wrote: > > multilib design (TM) is the (un)art of splitting only the libdir for > > archs and performing ugly hacks to cross-overwriting techniques. > > It's the art of splitting the libdir. The ugly hacks were an > implementation detail which are largely unnecessary when you stop and > actually think about it. Well, let's not argue about what the true definition of the word multilib is. That's why I called your version of multilib "David ... multilib". For clarities sake let's just call mulitlib what is known as multilib in Fedora since FC1.92 and not what we'd like it to had been, or what gcc calls multilib, or what Solaris calls it. > > As such the punchhole remove/install problem is an embedded issue of > > the multilib design (TM). > > Not at all. It's just an aspect of the dirty hack we put in RPM to allow > conflicting binaries to be installed. Not a fundamental problem with > multilib at all. See above, no need to really argue on words, let's solve the technical parts and we can call it multiwoods or foresthouse or bin64. ;) > > The "David Woodhouse improved multilib design that requires bin > > suppackage splits for every bin carrying package" tries to circumvent > > this problem by spliting out the bin contents in subpackages. But this > > is another bad short-term decision, as it > > > > o forces us to revisit every bin carrying package out there speding > > tons of resources better used elsewhere > > You overestimate the effort involved. It can be checked automatically, > and when conflicts are found, the fix is simple. Ok, a hands on example to demonstrate that this is not so: %build blah %install blub %files %{_bindir}/foo %{_datadir}/foo %files mon %{_sbindir}/foo-mon %{_localstatdir}/lib/foo-mon %files devel %{_bindir}/foo-config %{_includedir} So you want to sub-subpackage all three subpackages to a total of 6 subpackages with interesting set of intra-dependencies and you even claim that this will happen automatically w/o a human going through the specfiles? So let perl and sed automatically mungle the specfiles? Or what other automatic management would you apply? If a package required foo, does it now require foo-bin or foo ("the rest")? You can't know w/o reviewing this. Does foo-bin require foo ("the rest") or foo ("the rest") require foo-bin? You will find out that both is needed, so you will have tons of circular dependencies. In contast the bin64 proposal does not even have to look into the specfile (unless the specfile hardcoded /usr/bin or does other forbidden things we already have purged away from Fedora), no subpackage inflation, no overcmplicated intra- and interpackage depency relations, no tadpole loop depedencies. This is one of the rewarding moments where it pays of that we strictly made use of macros lijke _bindir in the specfiles. Not everything will build right into any random %_bindir definition, I'm not claiming that, but we'll get the huge majority built w/o touching the specfiles. > > o still does not allow us to simply have two disting repos for both > > arch, since we would have to filter out all bin subpackages > > No, because you _want_ both sets of bin subpackages available. The user > gets to install the secondary version _if_ they want it. > > > o If we don't filter then we just pass the problem to all depsolvers, > > e.g. yum, smart, apt > > No, those just install the primary architecture. The secondary arch only > ever gets installed if the user specifically asks for it. OK, then you have either a repo or two repos that by definition have almost as many conflicting packages at file conflict level as src.rpms exist. That's not only ugly, that breaks all package manager expectations from low level to any depsolver planted above rpm. That's not the clean concept w/o short-time hacks you are after. Did I notice that bin64 does not have these issues to begin with? bin64 is an extreme KISS approach that really does solve all multilib pain we have been having all these years. And ir required zero support from rpm, yum, smart, apt. And almost zero specfile rewrites. and full flexibility to let everyone do what they want, all groups will be satisfied. > > In comparison the bin64 solution costs us almost nothing: > > o most packages will rebuild in unattended mode > > o breakage of false bindir will be detected during the build itself > > o You can use two cleanly distinct repos with the depsolver tools of > > today, no need to add any funny support anywhere > > o You fix an FHS violation, in exchange for another, which just brings > > us bad to balance > > o The FHS has already considered this (thanks to the Debain folks) and > > is waiting for distros to actually utter the demand to include it. > > It buys you the ability to install _both_ versions of the package > simultaneously, but you can't easily choose which version to prefer for > a _specific_ package -- you can only set bin64 before or after bin in > $PATH, which affects _all_ installed programs. Always before. If you install both the default invocation makes bin64 win. The other arch is the legacy arch (at least for i386/x86_64), so it shouldn't default itself to higher priority. If both versions are installed, either a prefix like today's "i386" will mute the bin64 paths to stay only in the 32 bit world or calling something with its absolute path would be the user's way to express his choice between the 64/32 bit versions of the same binary. > Unless you split the packages out so that you can have libraries > installed for the secondary arch without having to have the > binaries, I suppose? :) That does not make sense at all. Because now you can't choose at all at runtime, you need to uninstall and install the other version, that's hardly a better way than to simply call a prefix to the command, just compare: bin64: yum install firefox.i386 firefox.x86_64 firefox -> 64 bit firefox, damn that flash website doesn't work goi386 firefox -> 32 bit firefox, view that ugly flash site firefox -> back to sane 64 bits Dave's multilib2: yum install firefox-bin.x86_64 firefox-libs.x86_64 firefox-libs.i386 firefox -> 64 bit firefox, damn that flash website doesn't work yum remove firefox-bin (wait) yum install firefox-bin.i386 (wait more, needs to be always online or have big yum cache) firefox -> 32 bit firefox, view that ugly flash site yum remove firefox-bin (wait) yum install firefox-bin.x86_64 (wait more, needs to be always online or have big yum cache) -- 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 Michael_E_Brown at dell.com Fri Apr 27 02:43:57 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 26 Apr 2007 21:43:57 -0500 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427002608.GC21691@neu.nirvana> References: <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> Message-ID: <20070427024357.GA4732@humbolt.us.dell.com> On Fri, Apr 27, 2007 at 02:26:08AM +0200, Axel Thimm wrote: > In contast the bin64 proposal does not even have to look into the > specfile (unless the specfile hardcoded /usr/bin or does other > forbidden things we already have purged away from Fedora), no > subpackage inflation, no overcmplicated intra- and interpackage > depency relations, no tadpole loop depedencies. The biggest issue I see with any bin64 issue is that you have a *huge* installed base of legacy software (and legacy software developers) who just assume that you can set a clean PATH to /usr/bin:/bin, and possibly /usr/sbin:/sbin. Lots of security-conscious software will do things like reset the PATH. Now all of a sudden, that no longer works. You have to either trust that PATH isnt set maliciously, or you have to know the arch you are on and that arch's specific peculariarities: prefer bin32 or bin64? etc. This sounds like a lot of pain and agony for lots of people and third-party software. -- Michael From notting at redhat.com Fri Apr 27 02:58:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Apr 2007 22:58:41 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427024357.GA4732@humbolt.us.dell.com> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> Message-ID: <20070427025841.GA6104@nostromo.devel.redhat.com> Michael E Brown (Michael_E_Brown at dell.com) said: > The biggest issue I see with any bin64 issue is that you have a *huge* > installed base of legacy software (and legacy software developers) who > just assume that you can set a clean PATH to /usr/bin:/bin, and possibly > /usr/sbin:/sbin. Lots of security-conscious software will do things like > reset the PATH. > > Now all of a sudden, that no longer works. You have to either trust that > PATH isnt set maliciously, or you have to know the arch you are on and > that arch's specific peculariarities: prefer bin32 or bin64? etc. > > This sounds like a lot of pain and agony for lots of people and > third-party software. Moreover, you move which binary you want to prefer from a packaging and installer issue to a global path ordering issue and the creation of wrappers. It's just dumb. Bill From lmacken at redhat.com Fri Apr 27 03:06:01 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 26 Apr 2007 23:06:01 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <4630F6BE.9060507@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <4630F6BE.9060507@redhat.com> Message-ID: <20070427030601.GB2673@tomservo.rh.rit.edu> On Thu, Apr 26, 2007 at 03:00:14PM -0400, Christopher Aillon wrote: > 'Cylon' +1. From notting at redhat.com Fri Apr 27 03:04:49 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 26 Apr 2007 23:04:49 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46311585.20204@redhat.com> References: <46311585.20204@redhat.com> Message-ID: <20070427030449.GC6104@nostromo.devel.redhat.com> Christopher Aillon (caillon at redhat.com) said: > On my system right now, /usr/share/locale takes up 373MB, dwarfing > whatever Firefox uses. Splitting out Firefox's langpacks won't solve > your problem. Moreover, splitting off of langpacks: - requires explicit support by adding packages in comps to work at all at initial install time - doesn't work at all if you're installing the package later It's a bad bad hack. Bill From jkeating at redhat.com Fri Apr 27 03:57:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Apr 2007 23:57:28 -0400 Subject: F7 Test4 freeze over, continued devel freeze. In-Reply-To: <1177618873.11826.5.camel@gibraltar.stuttgart.redhat.com> References: <200704261207.56702.jkeating@redhat.com> <1177618873.11826.5.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200704262357.29176.jkeating@redhat.com> On Thursday 26 April 2007 16:21:12 Nils Philippsen wrote: > excuse my ignorance ;-), but exactly what are we supposed to do to get > packages built a) between test 4 freeze and now and b) from now on? Is > "make COLLECTION=dist-fc7-final build" sufficient? no, not at all. You just do 'make build' as usual, and send a request to rel-eng at fedoraproject.org stating why your build should be in the final release. See http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy If you try to build into f7-final the build will happen, but the tag at the end will fail as the tag is locked. -- 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 lemenkov at gmail.com Fri Apr 27 04:14:26 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 27 Apr 2007 08:14:26 +0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46311585.20204@redhat.com> References: <46311585.20204@redhat.com> Message-ID: > On my system right now, /usr/share/locale takes up 373MB, dwarfing > whatever Firefox uses. Splitting out Firefox's langpacks won't solve > your problem. Does that the reason not to splitting Firefox? I think it's only the evidence that someone doesn't know something about macros in rpm configs. ) Take a look at %_install_langs macro - we can control installing langpacks using it but not in case of firefox. -- With best regards! From lemenkov at gmail.com Fri Apr 27 04:21:43 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 27 Apr 2007 08:21:43 +0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <20070427030449.GC6104@nostromo.devel.redhat.com> References: <46311585.20204@redhat.com> <20070427030449.GC6104@nostromo.devel.redhat.com> Message-ID: > Moreover, splitting off of langpacks: > - requires explicit support by adding packages in comps to work at > all at initial install time I don't think that's a hard work... > - doesn't work at all if you're installing the package later What actually doesn't work? Does Firefox will not start at all w/o them? No, it starts. If you will need some your favorite locale you may install it later. -- With best regards! From lemenkov at gmail.com Fri Apr 27 04:24:53 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 27 Apr 2007 08:24:53 +0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46311056.8040004@herr-schmitt.de> References: <46311056.8040004@herr-schmitt.de> Message-ID: 2007/4/27, Jochen Schmitt : > Peter Lemenkov schrieb: > > I think that it would be reasonable to split firefox into main > > application package and many language packs. > I agree with you, There should be the following packages: > > firefox (The main package) > firefox-devel (Package for development) > firefox-langpack-xx (Language-Pack) Yes. That's packaging scheme I'm talking about. > If you may do this, you may create a ticket for thunderbird too, becouse > there you have the same situation. I don't use thunderbird - I've got Gmail account ) -- With best regards! From notting at redhat.com Fri Apr 27 04:54:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Apr 2007 00:54:35 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: References: <46311585.20204@redhat.com> <20070427030449.GC6104@nostromo.devel.redhat.com> Message-ID: <20070427045435.GD6993@nostromo.devel.redhat.com> Peter Lemenkov (lemenkov at gmail.com) said: > >- doesn't work at all if you're installing the package later > > What actually doesn't work? Does Firefox will not start at all w/o > them? No, it starts. If you will need some your favorite locale you > may install it later. And how do you know what's available? How do you know that you need it? You've just made every firefox user in non-english have to go digging through comps to find firefox-langpack-; it's a horrible user experience. Bill From lemenkov at gmail.com Fri Apr 27 05:10:14 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Fri, 27 Apr 2007 09:10:14 +0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <20070427045435.GD6993@nostromo.devel.redhat.com> References: <46311585.20204@redhat.com> <20070427030449.GC6104@nostromo.devel.redhat.com> <20070427045435.GD6993@nostromo.devel.redhat.com> Message-ID: 2007/4/27, Bill Nottingham : > Peter Lemenkov (lemenkov at gmail.com) said: > > >- doesn't work at all if you're installing the package later > > > > What actually doesn't work? Does Firefox will not start at all w/o > > them? No, it starts. If you will need some your favorite locale you > > may install it later. > And how do you know what's available? Take a look at graphical frontends for Yum :) Seriously speaking - in the same manner to OpenOffice.org > How do you know that you need it? ? Kinda phylosophy? If anyone doesn't know why he need I have no idea too ) > You've just made every firefox user in non-english have to go > digging through comps to find firefox-langpack-; it's a horrible > user experience. You are grossly overestimating needed efforts. Don't speak about us, fellow users, as of idiots. -- With best regards! From Fedora at FamilleCollet.com Fri Apr 27 05:11:12 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 27 Apr 2007 07:11:12 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: References: Message-ID: <463185F0.7070209@FamilleCollet.com> Peter Lemenkov a ?crit : > Hello All! > I found another one thing that was made unpractically. We got > langpacks for 40 different languages that occupies ~12 MBytes from 43 > Mbytes. This situatuin is drastically dioffers fron one with > OpenOffice.org whose langpacks are not shipped with main app. Size is not the main problem i think. Time used to check extensions at first launch is another. Extension list is also quite big. What will occur when we also have the dictionnaries ? (more than 40 new extensions). What will occur if we install "enigmail", thunderbird extension, (i'm working on an RPM for this that i will submit for Extras). This package should follow the Fedora usage and come with more than 20 language packs. And probably other extensions... > > I think that it would be reasonable to split firefox into main > application package and many language packs. Yes, it's seems reasonnable to me The "target" could be - firefox - firefox-devel - firefox- - firefox-langpack- with dictionnaries, langpack for firefox and extensions Regards From notting at redhat.com Fri Apr 27 05:28:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Apr 2007 01:28:09 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <20070427045435.GD6993@nostromo.devel.redhat.com> References: <46311585.20204@redhat.com> <20070427030449.GC6104@nostromo.devel.redhat.com> <20070427045435.GD6993@nostromo.devel.redhat.com> Message-ID: <20070427052809.GE6993@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > > What actually doesn't work? Does Firefox will not start at all w/o > > them? No, it starts. If you will need some your favorite locale you > > may install it later. > > And how do you know what's available? How do you know that you need > it? You've just made every firefox user in non-english have to go > digging through comps to find firefox-langpack-; it's a horrible > user experience. I might add that in the case of Firefox you're talking about 12MB of on-disk space. That's three-tenths of a cent of hard drive space. 14 cents of flash storage. Six *hundreths* of a cent of DVD-R space. Not every place has the same prices, but, really - Fedora is not intended to be an embedded distribution, or specifically targeted at very small machines. Another example - kde-i18n contains translations for all KDE software. So, even if you're trying to install just a subset of KDE (kdebase? kdemultimedia), if you want to install translations, you have to install the translations for ktuberling or korn. With this, it's no shock that the KDE live CD can't support a variety of locales at the moment. For another example, moodle currently creates *68* language packs, totalling about 14MB in size. In order to support these 68 separate subpackages, any user who merely accesses a repository containing moodle, *even if they've never installed it*, has to download and process 16k more of data every time yum accesses the repository (not even counting the comps data). Whether that makes a difference in the grand scheme of things, I don't know. Bill From notting at redhat.com Fri Apr 27 05:34:48 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 Apr 2007 01:34:48 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: References: <46311585.20204@redhat.com> <20070427030449.GC6104@nostromo.devel.redhat.com> <20070427045435.GD6993@nostromo.devel.redhat.com> Message-ID: <20070427053448.GF6993@nostromo.devel.redhat.com> Peter Lemenkov (lemenkov at gmail.com) said: > >And how do you know what's available? > > Take a look at graphical frontends for Yum :) > Seriously speaking - in the same manner to OpenOffice.org I'm not saying OO.o is any *less* broken. > >How do you know that you need it? > > Kinda phylosophy? > If anyone doesn't know why he need I have no idea too ) You're a user who just installed firefox, or openoffice. Why would it make sense for you to go back into the package manager and select something else (not in the group with the package you just installed) just so your new app is localised in the same manner that your desktop already is, rather than having it just work for you? If you really want to perpetuate this mess, first write the yum plugin that automatically applies langsupport conditionals on package installs if a particular langsupport group is already installed. > >You've just made every firefox user in non-english have to go > >digging through comps to find firefox-langpack-; it's a horrible > >user experience. > > You are grossly overestimating needed efforts. It adds effort where there currently is no effort, for negligible benefit. > Don't speak about us, fellow users, as of idiots. I fail to see where I did that. Bill From j.w.r.degoede at hhs.nl Fri Apr 27 06:25:51 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Apr 2007 08:25:51 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46311585.20204@redhat.com> References: <46311585.20204@redhat.com> Message-ID: <4631976F.6050006@hhs.nl> Christopher Aillon wrote: > Peter Lemenkov wrote: >> Hello All! >> I found another one thing that was made unpractically. We got >> langpacks for 40 different languages that occupies ~12 MBytes from 43 >> Mbytes. This situatuin is drastically dioffers fron one with >> OpenOffice.org whose langpacks are not shipped with main app. >> >> I think that it would be reasonable to split firefox into main >> application package and many language packs. > > On my system right now, /usr/share/locale takes up 373MB, dwarfing > whatever Firefox uses. Which people who do minimal installs can (and do) bring down to close to 0 by %_install_langs to something different to all in %{_libdir}/rpm/macros > Splitting out Firefox's langpacks won't solve > your problem. > Actualy it will because I'm pretty sure that Peter is already using %_install_langs and probably also %_excludedocs May I suggest however that a much better solution would be to use %lang XXX int he %files list for the langpacks, that way if Peter indeed is using %_install_langs, then he will automatically use the lnagpacks to without all the downsides of using seperate langpack sub packages Regards, Hans From fedora at leemhuis.info Fri Apr 27 07:06:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 27 Apr 2007 09:06:39 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4631976F.6050006@hhs.nl> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> Message-ID: <4631A0FF.70209@leemhuis.info> On 27.04.2007 08:25, Hans de Goede wrote: > Christopher Aillon wrote: > [...] > May I suggest however that a much better solution would be to use %lang XXX int > he %files list for the langpacks, that way if Peter indeed is using > %_install_langs, then he will automatically use the lnagpacks to without all > the downsides of using seperate langpack sub packages Just playing devils advocate: downloads are bigger if all the langpacks are in the main package. Anyway, that's a problem presto might solve soon. But we have langpacks in openoffice and kde as well as dictionaries (aspell, hunspell,...). Maybe we should work towards a proper solution so yum/pirut installs the langpacks and dictionaries automatically where it makes sense. Then big langpacks could be split off in other apps as well (e.g. firefox and thunderbird). CU thl From nicolas.mailhot at laposte.net Fri Apr 27 07:16:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Apr 2007 09:16:01 +0200 (CEST) Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <4630F6BE.9060507@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <4630F6BE.9060507@redhat.com> Message-ID: <64726.192.54.193.51.1177658161.squirrel@rousalka.dyndns.org> Le Jeu 26 avril 2007 21:00, Christopher Aillon a ?crit : > - Tapwave Zod > > - A rather shortlived gaming platform. The official name was the > Zodiac, but it went by Zod for short (gaming geeks, go figure). I like zodiac. Lots of possibilities there -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Apr 27 07:34:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Apr 2007 09:34:14 +0200 (CEST) Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426193041.GB14127@neu.nirvana> References: <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> Message-ID: <63742.192.54.193.51.1177659254.squirrel@rousalka.dyndns.org> Le Jeu 26 avril 2007 21:30, Axel Thimm a ?crit : > As such the punchhole remove/install problem is an embedded issue of > the multilib design (TM). Actually if you want to go to the core issue, that's that no one ever decided what a rpm package was : A is it a container with invariant mandatory content? B is it a container with mixed mandatory and semi-optional content, that may be installed or not depending on system settings, various euristics and the phase of the moon? If the answer is A, puncholes are unacceptable, langpacks must be split... and yum taught smarts to reassemble all the resulting subpackages because raw access will overwhelm users. (dumb packages smart package manager option) If the answer is B loads of smarts must be added to rpm so all the optionnal stuff actually works without side effects. Also that means fat packages and big downloads. (smart packages dumb package manager option) Either way is loads of work because we let out tools bitrot for years, and now we find the workaround pile is not up to the new multi-arch multi-repo world. I personnaly think A is the cleaner design, but that's up to the tool writers to decide (Paul Nasrat, Seith Vidal...). Likewise yum effectively deprecated parallel rpm installs and rpm relocation a few years ago. -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Fri Apr 27 07:34:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 09:34:49 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427024357.GA4732@humbolt.us.dell.com> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> Message-ID: <20070427073449.GA31607@neu.nirvana> On Thu, Apr 26, 2007 at 09:43:57PM -0500, Michael E Brown wrote: > On Fri, Apr 27, 2007 at 02:26:08AM +0200, Axel Thimm wrote: > > > In contast the bin64 proposal does not even have to look into the > > specfile (unless the specfile hardcoded /usr/bin or does other > > forbidden things we already have purged away from Fedora), no > > subpackage inflation, no overcmplicated intra- and interpackage > > depency relations, no tadpole loop depedencies. > > The biggest issue I see with any bin64 issue is that you have a *huge* > installed base of legacy software (and legacy software developers) who > just assume that you can set a clean PATH to /usr/bin:/bin, and possibly > /usr/sbin:/sbin. Lots of security-conscious software will do things like > reset the PATH. That's correct, but how many packages will that affect? cron and what else? It's a low count number, and if the package does not allow to tune these during build it's questionable anyway, since there is no "one true and only path". For example we already have the very non-canonical legacy kerberos path example, and kerberos does count as security related. Did the non-canonical path of kerberos really block its introduction? > Now all of a sudden, that no longer works. You have to either trust that > PATH isnt set maliciously, or you have to know the arch you are on and > that arch's specific peculariarities: prefer bin32 or bin64? etc. No, never trust the path, and never detect at runtime. The bin64 proposal does the work at build time. rootkit.x86_64's resetting will have both paths, and rootkit.i386 only the non-bin64 paths. > This sounds like a lot of pain and agony for lots of people and > third-party software. Ask yourself if that was that the case with kerberos, too. Ask yourself how "big" the pain with /usr/X11R6/bin was. Compare that "pain" with the pain we are having now with multilib, or we would have with rewriting each and every specfile that has any bin components. No solution is just pressing a button, but there are some that require like 10% work of others with better results. -- 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 enrico.scholz at informatik.tu-chemnitz.de Fri Apr 27 07:39:06 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 27 Apr 2007 09:39:06 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46311585.20204@redhat.com> (Christopher Aillon's message of "Thu, 26 Apr 2007 17:11:33 -0400") References: <46311585.20204@redhat.com> Message-ID: <877irye06d.fsf@kosh.bigo.ensc.de> Christopher Aillon writes: >> I think that it would be reasonable to split firefox into main >> application package and many language packs. > > On my system right now, /usr/share/locale takes up 373MB, dwarfing > whatever Firefox uses. Probably caused by the removal of %_install_lang support in anaconda. Setting | %_install_langs C:de:en:es:fr gives | # du -sbh usr/share/locale/ usr/lib/firefox-2.0.0.3/extensions usr/lib/thunderbird-1.5.0.10/extensions | 18M usr/share/locale/ | 13M usr/lib/firefox-2.0.0.3/extensions | 12M usr/lib/thunderbird-1.5.0.10/extensions on a FC6.92 based small Gnome installation > Splitting out Firefox's langpacks won't solve your problem. Separate langpacks make it possible to install support for new languages. %lang requires package removal plus reinstallation; this was given as an argument against the %_install_lang feature in anaconda too. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From caillon at redhat.com Fri Apr 27 07:41:37 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 27 Apr 2007 03:41:37 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <463185F0.7070209@FamilleCollet.com> References: <463185F0.7070209@FamilleCollet.com> Message-ID: <4631A931.9070505@redhat.com> Remi Collet wrote: > Peter Lemenkov a ?crit : >> Hello All! >> I found another one thing that was made unpractically. We got >> langpacks for 40 different languages that occupies ~12 MBytes from 43 >> Mbytes. This situatuin is drastically dioffers fron one with >> OpenOffice.org whose langpacks are not shipped with main app. > > Size is not the main problem i think. > > Time used to check extensions at first launch is another. But that's considered a bug that should be fixed. From sundaram at fedoraproject.org Fri Apr 27 07:45:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 27 Apr 2007 13:15:13 +0530 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4631A0FF.70209@leemhuis.info> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> <4631A0FF.70209@leemhuis.info> Message-ID: <4631AA09.4090805@fedoraproject.org> Thorsten Leemhuis wrote: > But we have langpacks in openoffice and kde as well as dictionaries > (aspell, hunspell,...). Maybe we should work towards a proper solution > so yum/pirut installs the langpacks and dictionaries automatically where > it makes sense. Then big langpacks could be split off in other apps as > well (e.g. firefox and thunderbird). Right. Whatever the correct solution is should be applied across the repository instead of complete inconsistency. Openoffice.org with multiple language packs, KDE with a single language pack and Firefox with everything in the same package. Firefox having everything in the same package is a common user complaint in fedora-list and forums especially since it bloats the package to over double the usual size and the extensions are visible in the user interface. Rahul From Axel.Thimm at ATrpms.net Fri Apr 27 07:49:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 09:49:39 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427025841.GA6104@nostromo.devel.redhat.com> References: <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> Message-ID: <20070427074939.GB31607@neu.nirvana> On Thu, Apr 26, 2007 at 10:58:41PM -0400, Bill Nottingham wrote: > Michael E Brown (Michael_E_Brown at dell.com) said: > > The biggest issue I see with any bin64 issue is that you have a *huge* > > installed base of legacy software (and legacy software developers) who > > just assume that you can set a clean PATH to /usr/bin:/bin, and possibly > > /usr/sbin:/sbin. Lots of security-conscious software will do things like > > reset the PATH. > > > > Now all of a sudden, that no longer works. You have to either trust that > > PATH isnt set maliciously, or you have to know the arch you are on and > > that arch's specific peculariarities: prefer bin32 or bin64? etc. > > > > This sounds like a lot of pain and agony for lots of people and > > third-party software. > > Moreover, you move which binary you want to prefer from a packaging > and installer issue to a global path ordering issue and the creation > of wrappers. > > It's just dumb. No, it's just great and KISS. All the pain in multilib is there because it was designed to be managed by the package manager and not really works w/o it. Do you consider the multilib mess in rpm, both design wise (remove/install hole punching) and the 1001 multilib bugs from doubling most configs with rpmnew siblings to killing %doc and %lang to silently mute all conflicts to be non-dumb? As alternatives you have o Reduce the use cases of multilib (e.g. like at < FC5 time, only support selected cases of runtime, only pollute the repo with pure lib legacy arch packages, or at least try to) => nice and clean minimal solution, but since it was abandoned, it seems like someone thought people need more o Rewrite almost all specfiles to sub-subpackage *-bin and manage the conflicting bin suppackages => Overly compley with lots of implications, see my mail to David o Rewrite multilib support in rpm, and while there rewrite rpm, still you'll always have the punched holes syndrome. => Waiting for Godot o bin64 => FHS persuasion powers, fix cron o Live with the current situation => pain Personally I prefer the first one, but from the rest bin64 is the least dumb one. Or make another suggestion. -- 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 Fri Apr 27 07:57:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 09:57:18 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <63742.192.54.193.51.1177659254.squirrel@rousalka.dyndns.org> References: <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <63742.192.54.193.51.1177659254.squirrel@rousalka.dyndns.org> Message-ID: <20070427075718.GC31607@neu.nirvana> On Fri, Apr 27, 2007 at 09:34:14AM +0200, Nicolas Mailhot wrote: > Le Jeu 26 avril 2007 21:30, Axel Thimm a ?crit : > > > As such the punchhole remove/install problem is an embedded issue of > > the multilib design (TM). > > Actually if you want to go to the core issue, that's that no one ever > decided what a rpm package was : > A is it a container with invariant mandatory content? > B is it a container with mixed mandatory and semi-optional content, > that may be installed or not depending on system settings, various > euristics and the phase of the moon? > > If the answer is A, puncholes are unacceptable, langpacks must be > split... and yum taught smarts to reassemble all the resulting > subpackages because raw access will overwhelm users. (dumb packages > smart package manager option) I think the answer was always A until multilib support was added and one found out that one would have to violate this not caring about the punchhole syndrom back then. But why would it require to split out langpacks? These are usually exactly the same on all archs, so the usual "If two packages share the same files, they don't conflict" package rule applies and all is well, or not? > If the answer is B loads of smarts must be added to rpm so all the > optionnal stuff actually works without side effects. Also that means > fat packages and big downloads. (smart packages dumb package manager > option) Don't forget that it will also need a way to detect the moon phases :) > Either way is loads of work because we let out tools bitrot for years, > and now we find the workaround pile is not up to the new multi-arch > multi-repo world. > > I personnaly think A is the cleaner design, but that's up to the tool > writers to decide (Paul Nasrat, Seith Vidal...). Likewise yum > effectively deprecated parallel rpm installs and rpm relocation a few > years ago. A for president! -- 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 Fri Apr 27 06:26:47 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 27 Apr 2007 08:26:47 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426220250.39a9012c@ludwig-alpha.unil.ch> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> <20070426115203.630dd309@daggett> <20070426220250.39a9012c@ludwig-alpha.unil.ch> Message-ID: <1177655207.30803.710.camel@mccallum.corsepiu.local> On Thu, 2007-04-26 at 22:02 +0200, Christian Iseli wrote: > On Thu, 26 Apr 2007 11:52:03 -0400, Ed Hill wrote: > > I would like to see Fedora adopt the {,/usr}/{,s}bin64 handling as > > described by Axel. Or something very similar to it. > > > > If it is possible (and I think it is), I'd like to have a framework > > that allows *full* co-existence of 32-bit and 64-bit packages. > > I'm pretty lost here... Why would anyone want a multiarch system ? /me thinks people are mixing up two different objectives of multiarched systems, here: Traditionally there are two fundamentally different approaches to multiarched systems: 1. Using one base architecture but have "secondary architectures" for "backward compatible" applications. Most common case is: "Running 32bit-apps on 64bit systems" 2. Seamlessly booting a system into different architectures without reinstallation/reconfiguration. An example would be alternatively booting a system with 64bit support on HW into "32bit" or "64bit" mode without changing the installation. > I understand multilib a bit better. It can be useful when a > particular tool (e.g. firefox and its plugins) work better on one arch > than on the other one. Wrt. firefox probably is a case of 1. above. > we already have chroots and virtual machines, so what more does it > buy us to get a big mess of duplicated things? multilibs (in GCC's terms) provide a very efficient way to natively cross compile (i.e. use native tools to compile for a non-native architecture). In a perfect world, normal users would never need any of the "secondary arch'ed" packages, only developers would have to install the "secondary arch'ed" *-devel packages. Ralf From nicolas.mailhot at laposte.net Fri Apr 27 08:31:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Apr 2007 10:31:28 +0200 (CEST) Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427075718.GC31607@neu.nirvana> References: <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <63742.192.54.193.51.1177659254.squirrel@rousalka.dyndns.org> <20070427075718.GC31607@neu.nirvana> Message-ID: <41863.192.54.193.51.1177662688.squirrel@rousalka.dyndns.org> > But why would it require to split out langpacks? These are usually > exactly the same on all archs, so the usual "If two packages share the > same files, they don't conflict" package rule applies and all is well, > or not? Because if you posit packages with invariant content, you can't punch holes in packages to remove the locales the user does not want on his system -- Nicolas Mailhot From Christian.Iseli at licr.org Fri Apr 27 08:32:07 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 27 Apr 2007 10:32:07 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427074939.GB31607@neu.nirvana> References: <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> Message-ID: <20070427103207.6ea159fd@ludwig-alpha.unil.ch> On Fri, 27 Apr 2007 09:49:39 +0200, Axel Thimm wrote: > o Rewrite almost all specfiles to sub-subpackage *-bin and manage the > conflicting bin suppackages Why almost all packages containing bins? If we have: - package A contains *both* libs and bins - package B uses libs from package A - it makes some sense to have 32-bit and 64-bit versions of package B installed in different situations *then* it makes some sense (to me) to rewrite package A's spec to split out the lib part. But I'm hardly convinced that represents "almost all specfiles". C From Axel.Thimm at ATrpms.net Fri Apr 27 08:35:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 10:35:19 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <41863.192.54.193.51.1177662688.squirrel@rousalka.dyndns.org> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <63742.192.54.193.51.1177659254.squirrel@rousalka.dyndns.org> <20070427075718.GC31607@neu.nirvana> <41863.192.54.193.51.1177662688.squirrel@rousalka.dyndns.org> Message-ID: <20070427083519.GE31607@neu.nirvana> On Fri, Apr 27, 2007 at 10:31:28AM +0200, Nicolas Mailhot wrote: > > > But why would it require to split out langpacks? These are usually > > exactly the same on all archs, so the usual "If two packages share the > > same files, they don't conflict" package rule applies and all is well, > > or not? > > Because if you posit packages with invariant content, you can't punch > holes in packages to remove the locales the user does not want on his > system Ah, OK, I thought it was multilib relevant, because there is also some implemenation bug with multilib and %lang. -- 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 Fri Apr 27 08:40:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 10:40:06 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427103207.6ea159fd@ludwig-alpha.unil.ch> References: <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> Message-ID: <20070427084006.GF31607@neu.nirvana> > On Fri, Apr 27, 2007 at 10:32:07AM +0200, Christian Iseli wrote: > > On Fri, 27 Apr 2007 09:49:39 +0200, Axel Thimm wrote: > > o Reduce the use cases of multilib (e.g. like at < FC5 time, only > > support selected cases of runtime, only pollute the repo with pure > > lib legacy arch packages, or at least try to) > > => nice and clean minimal solution, but since it was abandoned, it > > seems like someone thought people need more > > o Rewrite almost all specfiles to sub-subpackage *-bin and manage the > > conflicting bin suppackages > > => Overly compley with lots of implications, see my mail to David > Why almost all packages containing bins? > > If we have: > - package A contains *both* libs and bins > - package B uses libs from package A > - it makes some sense to have 32-bit and 64-bit versions of package B > installed in different situations > *then* it makes some sense (to me) to rewrite package A's spec to split > out the lib part. > > But I'm hardly convinced that represents "almost all specfiles". You're mixing things, what you describe is the first item, while the second is David's suggestion of splitting out all bin parts to separate *-bin sub-subpackages and have them conflict. I'm not fond about this model, either, and I prefer the first one as well (minimal runtime support for selected packages), but for completeness and fairness sake, it needs to be on the list. > > o Rewrite multilib support in rpm, and while there rewrite rpm, still > > you'll always have the punched holes syndrome. > > => Waiting for Godot > > o bin64 > > => FHS persuasion powers, fix cron > > o Live with the current situation > > => pain -- 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 Christian.Iseli at licr.org Fri Apr 27 08:44:59 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Fri, 27 Apr 2007 10:44:59 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177655207.30803.710.camel@mccallum.corsepiu.local> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> <20070426115203.630dd309@daggett> <20070426220250.39a9012c@ludwig-alpha.unil.ch> <1177655207.30803.710.camel@mccallum.corsepiu.local> Message-ID: <20070427104459.1aecb254@ludwig-alpha.unil.ch> On Fri, 27 Apr 2007 08:26:47 +0200, Ralf Corsepius wrote: > multilibs (in GCC's terms) provide a very efficient way to natively > cross compile (i.e. use native tools to compile for a non-native > architecture). yes > In a perfect world, normal users would never need any of > the "secondary arch'ed" packages, only developers would have to install > the "secondary arch'ed" *-devel packages. That's my understanding as well, and that's where I'd like to aim our efforts C From nicolas.mailhot at laposte.net Fri Apr 27 08:57:46 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 27 Apr 2007 10:57:46 +0200 (CEST) Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427083519.GE31607@neu.nirvana> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <63742.192.54.193.51.1177659254.squirrel@rousalka.dyndns.org> <20070427075718.GC31607@neu.nirvana> <41863.192.54.193.51.1177662688.squirrel@rousalka.dyndns.org> <20070427083519.GE31607@neu.nirvana> Message-ID: <41550.192.54.193.51.1177664266.squirrel@rousalka.dyndns.org> Le Ven 27 avril 2007 10:35, Axel Thimm a ?crit : > On Fri, Apr 27, 2007 at 10:31:28AM +0200, Nicolas Mailhot wrote: >> >> > But why would it require to split out langpacks? These are usually >> > exactly the same on all archs, so the usual "If two packages share >> the >> > same files, they don't conflict" package rule applies and all is >> well, >> > or not? >> >> Because if you posit packages with invariant content, you can't >> punch >> holes in packages to remove the locales the user does not want on >> his >> system > > Ah, OK, I thought it was multilib relevant, because there is also some > implemenation bug with multilib and %lang. There are bugs in all the workarounds added over the years to make parts of packages (localisation, multilib) optional. The question is do we want to fix the workarounds or forbid package variability -- Nicolas Mailhot From nphilipp at redhat.com Fri Apr 27 09:48:45 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 27 Apr 2007 11:48:45 +0200 Subject: F7 Test4 freeze over, continued devel freeze. In-Reply-To: <200704262357.29176.jkeating@redhat.com> References: <200704261207.56702.jkeating@redhat.com> <1177618873.11826.5.camel@gibraltar.stuttgart.redhat.com> <200704262357.29176.jkeating@redhat.com> Message-ID: <1177667326.13844.18.camel@gibraltar.stuttgart.redhat.com> On Thu, 2007-04-26 at 23:57 -0400, Jesse Keating wrote: > On Thursday 26 April 2007 16:21:12 Nils Philippsen wrote: > > excuse my ignorance ;-), but exactly what are we supposed to do to get > > packages built a) between test 4 freeze and now and b) from now on? Is > > "make COLLECTION=dist-fc7-final build" sufficient? > > no, not at all. You just do 'make build' as usual, and send a request to > rel-eng at fedoraproject.org stating why your build should be in the final done > release. See > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From Axel.Thimm at ATrpms.net Fri Apr 27 10:49:53 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 12:49:53 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <41550.192.54.193.51.1177664266.squirrel@rousalka.dyndns.org> References: <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <63742.192.54.193.51.1177659254.squirrel@rousalka.dyndns.org> <20070427075718.GC31607@neu.nirvana> <41863.192.54.193.51.1177662688.squirrel@rousalka.dyndns.org> <20070427083519.GE31607@neu.nirvana> <41550.192.54.193.51.1177664266.squirrel@rousalka.dyndns.org> Message-ID: <20070427104953.GH31607@neu.nirvana> On Fri, Apr 27, 2007 at 10:57:46AM +0200, Nicolas Mailhot wrote: > > Le Ven 27 avril 2007 10:35, Axel Thimm a ?crit : > > On Fri, Apr 27, 2007 at 10:31:28AM +0200, Nicolas Mailhot wrote: > >> > >> > But why would it require to split out langpacks? These are usually > >> > exactly the same on all archs, so the usual "If two packages share > >> the > >> > same files, they don't conflict" package rule applies and all is > >> well, > >> > or not? > >> > >> Because if you posit packages with invariant content, you can't > >> punch > >> holes in packages to remove the locales the user does not want on > >> his > >> system > > > > Ah, OK, I thought it was multilib relevant, because there is also some > > implemenation bug with multilib and %lang. > > There are bugs in all the workarounds added over the years to make > parts of packages (localisation, multilib) optional. The question is > do we want to fix the workarounds or forbid package variability Well, some of the workaround like punching holes during remove/installs are not fixable otherwise. But there is a differnece between unvoluntarily overwriting stuff (like installing/removing x86_64 over i386) and users selecting to do so (like wanting to choose M out of N languages). For the langpack issue I guess that having the large consumers split the packages (like it is being done now) is OK, but let the mini langpacks consuming little space as a whole (e.g. not a sub-package per lang). I think the langpack discussion is bit different from the multilib, so we shouldn't really mix them. Most of the multilib solutions like bin64, sub-sub-bins, minimal lib-support and so on don't affect the langpacks at all, and similar for any langpack split policy that may come up, e.g. whatever we end up modifying with langpacks it will not really help with multilib. -- 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 dwmw2 at infradead.org Fri Apr 27 10:59:57 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 Apr 2007 11:59:57 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427103207.6ea159fd@ludwig-alpha.unil.ch> References: <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> Message-ID: <1177671597.2755.504.camel@pmac.infradead.org> On Fri, 2007-04-27 at 10:32 +0200, Christian Iseli wrote: > Why almost all packages containing bins? > > If we have: > - package A contains *both* libs and bins > - package B uses libs from package A > - it makes some sense to have 32-bit and 64-bit versions of package B > installed in different situations > *then* it makes some sense (to me) to rewrite package A's spec to split > out the lib part. > > But I'm hardly convinced that represents "almost all specfiles". You're right; there is perhaps _some_ logic in allowing packages to contain both libraries and executables _if_ that package isn't expected to be installed for both architectures simultaneously. We wouldn't need to change the whole package set in one fell swoop. OTOH if we make it a blanket rule, it's a lot easier to check for it automatically and thus to fix the occurrences. There are arguments boths ways. Let's take a look... In the early spin of F7t4 I happen to have lying around, there are 1286 32-bit binary packages. Of those, 516 have binaries (rpm -qlp $a | grep /bin/) while 343 have libraries (grep '/lib/[^/]*.so\..*'). Note that I've limited it to libraries in /usr/lib -- so packages like evolution which provide their _own_ libraries in /usr/lib/somepackage/*.so, for example, don't count.? The union of those lists is 126 binary packages -- less than 10% of the packages in the distribution which even need to be glanced at. Of those, almost all will be trivial to split. And some may well be false positives because they might only have _scripts_ in the binary dir, might have non-conflicting binaries (like /usr/bin/pango-querymodules-32 etc.) or on inspection we might conclude that the libraries would _only_ ever be required by the binary in the same package, so there's no need to ever have the libraries installed for both architectures at once. -- dwmw2 ? If I include _all_ libraries ('/lib/.*\.so.*') instead of only those on the search path, there are 792 packages with libraries, and the union of those with binaries is 245. There'll be a metric shitload of false positives in there, of course, but it puts the _upper_ bound at 20% of the packages even if we _want_ to overestimate it (as Axel seems to). From Axel.Thimm at ATrpms.net Fri Apr 27 12:13:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 14:13:08 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177671597.2755.504.camel@pmac.infradead.org> References: <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> Message-ID: <20070427121308.GB9711@neu.nirvana> On Fri, Apr 27, 2007 at 11:59:57AM +0100, David Woodhouse wrote: > On Fri, 2007-04-27 at 10:32 +0200, Christian Iseli wrote: > > Why almost all packages containing bins? > > > > If we have: > > - package A contains *both* libs and bins > > - package B uses libs from package A > > - it makes some sense to have 32-bit and 64-bit versions of package B > > installed in different situations > > *then* it makes some sense (to me) to rewrite package A's spec to split > > out the lib part. > > > > But I'm hardly convinced that represents "almost all specfiles". > > You're right; there is perhaps _some_ logic in allowing packages to > contain both libraries and executables _if_ that package isn't expected > to be installed for both architectures simultaneously. We wouldn't need > to change the whole package set in one fell swoop. > > OTOH if we make it a blanket rule, it's a lot easier to check for it > automatically and thus to fix the occurrences. There are arguments boths > ways. > > Let's take a look... > > In the early spin of F7t4 I happen to have lying around, there are 1286 > 32-bit binary packages. In today's rawhide of the upcoming merged F7 there are 6569, you already cut away 80% of the packages. You are not implying that we only fix 20% of the packages because they happen to be on the CD? Or that we constrain our analysis on only was has been cherry-picked for a spin and is know to be working multilib wise? > Of those, 516 have binaries (rpm -qlp $a | grep /bin/) Conveniently missing the sbins. > while 343 have libraries (grep '/lib/[^/]*.so\..*'). Note that I've > limited it to libraries in /usr/lib -- so packages like evolution > which provide their _own_ libraries in /usr/lib/somepackage/*.so, > for example, don't count.? Conveniently missing the *-devel packages. > The union of those lists is 126 binary packages Sounds more like an intersection to me. > -- less than 10% of the packages in the distribution which even need > to be glanced at. Of those, almost all will be trivial to split. And > some may well be false positives because they might only have > _scripts_ in the binary dir, might have non-conflicting binaries > (like /usr/bin/pango-querymodules-32 etc.) or on inspection we might > conclude that the libraries would _only_ ever be required by the > binary in the same package, so there's no need to ever have the > libraries installed for both architectures at once. OTOH you are missing all foo-config scripts that are in foo-devel and are arch specific, this outweights any false positives like the ones you describe. > ? If I include _all_ libraries ('/lib/.*\.so.*') instead of only > those on the search path, there are 792 packages with libraries, and > the union of those with binaries is 245. There'll be a metric > shitload of false positives in there, of course, but it puts the > _upper_ bound at 20% of the packages even if we _want_ to > overestimate it (as Axel seems to). How can I be overestimating, or estimating at all, if I never quoted any numbers? The reality is that you're playing it down, even when trying to back it up with numbers that leak false negatives here and there. A simple stats w/o all assumptions and sbin/devel filtering out gives (For clarification of stats: packages are binary not source) 8385 total packages in F7/i386 6569 i386 packages in F7/i386 (78%) 2862 i386 packages with binaries in F7/i386 (34%) 3096 i386 packages with libraries (under /usr/lib directly) in F7/i386 (37%) 1135 i386 with binaries and libs in F7/i386 (14%) So the true number is 14% amounting to 1135 packages, which *could* [1] amount to 606 specfiles, which amounts to 40% of today's rawhide FC. What is the rate of completed merge reviews? That could give you an idea of how many resources "fixing" these 606 package will need. So, if I have to give an estimate for a lower bound, it is 14% and 606 specfiles. And that's only for limiting to splitting off sub-sub-bins in presence of libs. And you still remain with the problem of conflicting packages, and haven't solved even the pkgconfig issue or firefox like issues (or any other category-similar issues), so basically all you did is avoid the punchole bug (which is good, of course), but at a high cost w/o much further side effects. Special handling is still needed at all other places. And now compare again to the bin64 case: Still far less work and higher gains, as it allows virtually any scenario, including using non-patched i386 pkgconfig/firefox etc. bits directly. You cover all target groups, those that you can think of today, and that that may come up tomorrow. [1] I'm just linearily scaling 4474 src.rpm -> 8385 creates binary/noarch packages. A more thorow analysis would be quoting src.rpms and not noarch/i386 numbers. -- 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 dwmw2 at infradead.org Fri Apr 27 13:20:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 Apr 2007 14:20:19 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427121308.GB9711@neu.nirvana> References: <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> Message-ID: <1177680019.2755.553.camel@pmac.infradead.org> On Fri, 2007-04-27 at 14:13 +0200, Axel Thimm wrote: > In today's rawhide of the upcoming merged F7 there are 6569, you > already cut away 80% of the packages. You are not implying that we > only fix 20% of the packages because they happen to be on the CD? > > Or that we constrain our analysis on only was has been cherry-picked > for a spin and is know to be working multilib wise? No, this is _all_ the ppc32 packages in the ppc compose. Although of course you're right that it doesn't include Extras. > > Of those, 516 have binaries (rpm -qlp $a | grep /bin/) > > Conveniently missing the sbins. Good point; thanks for pointing it out -- which was of course the reason why I included the precise method I used. So that takes the number to 613 instead of 516, and the intersection (doh, sorry) becomes 141 packages, from 139 source packages. > > while 343 have libraries (grep '/lib/[^/]*.so\..*'). Note that I've > > limited it to libraries in /usr/lib -- so packages like evolution > > which provide their _own_ libraries in /usr/lib/somepackage/*.so, > > for example, don't count.? > > Conveniently missing the *-devel packages. By omitting /usr/lib/*.so, you mean? OK, we can add that too if you want to nitpick '^(/usr|)/lib/[^/]*.so(|\..*)$'). Then we need to remove a bunch of false positives with just stuff like /usr/bin/pcre-config which is a script not an executable, and we gain 21 more source packages, for a total of 160 -- or 12%. > OTOH you are missing all foo-config scripts that are in foo-devel and > are arch specific, this outweights any false positives like the ones > you describe. If those are arch-specific then they're broken, because it means you can't currently build for both architectures correctly. And your solution doesn't help there either, because you still pick up the first one on $PATH instead of the _right_ one according to what you're compiling for. > 1135 i386 with binaries and libs in F7/i386 (14%) I could nitpick your precise numbers but there's no point -- that figure is within the noise margin of both my original and revised (above) estimates, and I'd only make myself look silly. We can keep refining it all day, but I don't really see the point unless we're actually going to start filing bugs against the ones which need splitting. > So the true number is 14% amounting to 1135 packages, which *could* > [1] amount to 606 specfiles, which amounts to 40% of today's rawhide > FC. What is the rate of completed merge reviews? That could give you > an idea of how many resources "fixing" these 606 package will need. The rate of completed reviews is totally irrelevant. Getting those done involves getting someone _else_ to pay attention to a package they don't necessarily care about. Since the bins vs. libs check can be automated, the package maintainer can do it themselves in a very short period of time -- and the need for it can be automatically flagged by the build system. So a more interesting statistic might be the number of binary packages which weren't rebuilt between FC6 and FC7 -- which is about 47 judging by the disttags. So if the problem is flagged on a rebuild, then only 4% of packages would get through to F8 without being automatically caught. And that's assuming we don't do a mass rebuild between now and then, which is unlikely. I think FC7 was the first time we haven't done one. > So, if I have to give an estimate for a lower bound, it is 14% and 606 > specfiles. And that's only for limiting to splitting off sub-sub-bins > in presence of libs. Yeah, that seems reasonable if we're going to insist on _all_ packages meeting the guidelines (which is required for it to be automatically caught, of course). If we are going to limit to those packages which a sensible user might _want_ to install for the secondary arch, then there's a lot of them which we don't need to 'fix'. Including most of what's currently in Extras, I would imagine. If we don't make it mandatory then it can easily be done piecemeal -- a given package can be fixed only if and when someone comes up with a good reason to have it installed in parallel and _tries_ it, and files a bug. I suspect we'd probably fix it in advance for everything currently in Core, and let the current Extras packages be converted as required. > And you still remain with the problem of conflicting packages, There is no _problem_ with conflicting packages. There are only conflicting packages, which you may not install simultaneously. > haven't solved even the pkgconfig issue or firefox like issues (or any > other category-similar issues), Neither have I solved world hunger. These are unrelated issues which as far as I can tell your solution doesn't solve either. If you have to have your $PATH set to /bin64 or /bin according to whether you're building for 64-bit or 32-bit, to make sure you pick up the right foo-config or pkgconfig .pc files, then that's still broken. And I'm not sure _what_ you're referring to w.r.t firefox. Once we have xulrunner (which can be installed for both arches simultaneously) and separate firefox (which can not), that all works just fine. You install plugins for one arch or the other, or both. There's no problem here. -- dwmw2 From katzj at redhat.com Fri Apr 27 13:27:35 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 27 Apr 2007 09:27:35 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4631A0FF.70209@leemhuis.info> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> <4631A0FF.70209@leemhuis.info> Message-ID: <1177680455.6907.7.camel@aglarond.local> On Fri, 2007-04-27 at 09:06 +0200, Thorsten Leemhuis wrote: > > On 27.04.2007 08:25, Hans de Goede wrote: > > Christopher Aillon wrote: > > [...] > > May I suggest however that a much better solution would be to use %lang XXX int > > he %files list for the langpacks, that way if Peter indeed is using > > %_install_langs, then he will automatically use the lnagpacks to without all > > the downsides of using seperate langpack sub packages > > Just playing devils advocate: downloads are bigger if all the langpacks > are in the main package. > > Anyway, that's a problem presto might solve soon. Of course, if you use %_install_langs, then deltarpms won't work as there are bits which aren't installed on your system and thus you can't recreate the pristine package. > But we have langpacks in openoffice and kde as well as dictionaries > (aspell, hunspell,...). Maybe we should work towards a proper solution > so yum/pirut installs the langpacks and dictionaries automatically where > it makes sense. Then big langpacks could be split off in other apps as > well (e.g. firefox and thunderbird). All of the sort of "conditional" stuff in the package managers are horrendous, awful hacks. Fundamentally and by design, it _cannot_ work nicely. There are just too many avenues of doing things which can confuse it or make the "correct" thing unclear. To be honest, I'd love to take every single one of the language support groups out of comps and in the process, end massive amounts of pain Jeremy From dwmw2 at infradead.org Fri Apr 27 13:35:12 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 Apr 2007 14:35:12 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177680019.2755.553.camel@pmac.infradead.org> References: <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> Message-ID: <1177680912.2755.557.camel@pmac.infradead.org> Hm, I apologise. I had previously said: "We've spent too long trying to take short-cuts and do the easiest thing in the _short_ term for multilib -- and it shows. It's time to start doing it properly, IMHBCO. "I'll entertain discussion about whether banning these conflicts is 'proper', but with all due respect I'm not too interested in discussion about the fact that it might actually take a small amount of work to fix the packaging so that we can remove this dirty problematic filecolours hack from RPM." And despite that earlier statement, I let myself get drawn back into such a discussion. I should have resisted. -- dwmw2 From ed at eh3.com Fri Apr 27 13:37:09 2007 From: ed at eh3.com (Ed Hill) Date: Fri, 27 Apr 2007 09:37:09 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177655207.30803.710.camel@mccallum.corsepiu.local> References: <462D18D4.5030403@hhs.nl> <1177419863.30803.242.camel@mccallum.corsepiu.local> <20070424151938.GT633@neu.nirvana> <1177476579.30803.359.camel@mccallum.corsepiu.local> <20070425085240.GD22427@neu.nirvana> <20070425111620.GD355@devserv.devel.redhat.com> <20070425165221.GO11831@neu.nirvana> <20070425170932.GA2995@free.fr> <20070425173942.GU11831@neu.nirvana> <20070426072923.GD5296@free.fr> <20070426081658.GC23704@neu.nirvana> <20070426115203.630dd309@daggett> <20070426220250.39a9012c@ludwig-alpha.unil.ch> <1177655207.30803.710.camel@mccallum.corsepiu.local> Message-ID: <20070427093709.3d6509be@daggett> On Fri, 27 Apr 2007 08:26:47 Ralf Corsepius wrote: > > Traditionally there are two fundamentally different approaches to > multiarched systems: > > 1. Using one base architecture but have "secondary architectures" for > "backward compatible" applications. > > Most common case is: "Running 32bit-apps on 64bit systems" > > 2. Seamlessly booting a system into different architectures without > reinstallation/reconfiguration. > > An example would be alternatively booting a system with 64bit support > on HW into "32bit" or "64bit" mode without changing the installation. Thank you for putting that succinctly! I am interested in both kinds of functionality -- running 32-bit programs on 64-bit machines (for testing purposes and "real use") *and* building 32-/64-bit software. I think it is sub-optimal to focus only on one of these aspects when (with perhaps only a tiny additional effort) you can have both. I am not 100% sure what is the best way to get both but the relatively simple ideas put forth by Axel deserve consideration IMO. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri Apr 27 13:45:20 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 27 Apr 2007 15:45:20 +0200 Subject: Attention: mikmod (was: Re: rawhide report: 20070427 changes) In-Reply-To: <200704270958.l3R9wbv6007777@hs20-bc2-6.build.redhat.com> References: <200704270958.l3R9wbv6007777@hs20-bc2-6.build.redhat.com> Message-ID: <20070427154520.469a507b.bugs.michael@gmx.net> On Fri, 27 Apr 2007 05:58:37 -0400, buildsys wrote: > mikmod-3.2.2-2.fc7 > ------------------ > * Sat Apr 21 2007 Jindrich Novy 3.2.2-2 > - downgrade libmikmod to avoid dependency problems before F7 release > - minor spec fixes With this downgrade I'm going to pull the few Extras rebuilds from the needsign queue, and then *all* mikmod deps should be fine again. No rebuilds necessary! Please ignore the private broken deps reports! From mclasen at redhat.com Fri Apr 27 13:56:20 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 27 Apr 2007 09:56:20 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: References: <46311585.20204@redhat.com> Message-ID: <1177682180.3495.7.camel@localhost.localdomain> On Fri, 2007-04-27 at 08:14 +0400, Peter Lemenkov wrote: > > On my system right now, /usr/share/locale takes up 373MB, dwarfing > > whatever Firefox uses. Splitting out Firefox's langpacks won't solve > > your problem. > > Does that the reason not to splitting Firefox? I think it's only the > evidence that someone doesn't know something about macros in rpm > configs. ) > > Take a look at %_install_langs macro - we can control installing > langpacks using it but not in case of firefox. So, this is just a request to add proper %lang annotations to the firefox file lists ? From j.w.r.degoede at hhs.nl Fri Apr 27 14:45:00 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 27 Apr 2007 16:45:00 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <1177682180.3495.7.camel@localhost.localdomain> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> Message-ID: <46320C6C.7090803@hhs.nl> Matthias Clasen wrote: > On Fri, 2007-04-27 at 08:14 +0400, Peter Lemenkov wrote: >>> On my system right now, /usr/share/locale takes up 373MB, dwarfing >>> whatever Firefox uses. Splitting out Firefox's langpacks won't solve >>> your problem. >> Does that the reason not to splitting Firefox? I think it's only the >> evidence that someone doesn't know something about macros in rpm >> configs. ) >> >> Take a look at %_install_langs macro - we can control installing >> langpacks using it but not in case of firefox. > > So, this is just a request to add proper %lang annotations to the > firefox file lists ? > Yes and no, Peter's original request really was for seperate (sub) packages. But Peter's problem can be solved too (and probably better) by adding proper %lang annotations to the firefox file lists. This all AFAIK. Regards, Hans From dominik at greysector.net Fri Apr 27 14:47:33 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 16:47:33 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426171322.GA7127@neu.nirvana> References: <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177579621.30803.579.camel@mccallum.corsepiu.local> <20070426115046.GM23704@neu.nirvana> <1177593137.30803.652.camel@mccallum.corsepiu.local> <20070426171322.GA7127@neu.nirvana> Message-ID: <20070427144733.GD20840@ryvius.pekin.waw.pl> On Thursday, 26 April 2007 at 19:13, Axel Thimm wrote: > On Thu, Apr 26, 2007 at 03:12:17PM +0200, Ralf Corsepius wrote: > > On Thu, 2007-04-26 at 13:50 +0200, Axel Thimm wrote: > > > On Thu, Apr 26, 2007 at 11:27:00AM +0200, Ralf Corsepius wrote: > > > > On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote: > > > > > On Thu, Apr 26, 2007 at 09:56:33AM +0100, David Woodhouse wrote: > > > > > > On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote: > > > > > > > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote: > > > > > > > > > > > [... Changing all specfiles by splitting out bin subpackages > > > > > > > > > > > vs simply defining a new _bindir ...] > > > > > > > > > > Yes, but it does involve much more work to do. > > > > > > > > > > > > > > > > Packaging is hard. Let's go shopping. > > > > > > > > > > > > > > No, the above is not hard to do, it is a straightforward thing to do > > > > > > > that will occupy a full or more than one release cycle(s). > > > > > > > > > > > > > > I prefer to get F8 with some new features as well and not only a mass > > > > > > > review again. Which wil involve thre times as many packages as the FC > > > > > > > merge review which we didn't manage to finish. > > > > > > > > > > > > Actually, this one should be quite easy to automate. > > > > > > > > > > > > We've spent too long trying to take short-cuts and do the easiest thing > > > > > > in the _short_ term for multilib -- and it shows. It's time to start > > > > > > doing it properly, IMHBCO. > > > > > > > > > > Exactly and the proper thing for multilib is: Let it die, multiarch rulez! > > > > > > > > Apparently you haven't understood what multilibs are. > > > > > > Obviously your personal definition of multilib includes > > > cross-compiling for x86_64 on i386. > > Yes, because THIS is multilib'ing. > > > > > But we call multilib something else here, please adjust. > > > > The concept of multilibs as being defined by GCC exists for than a > > decade (More precisely: <= 1995). > > > > What you are naming multilibs is mixing architectures at run-time. > > The correct term for this would be multi-arch'ing or bi-arch'ing as far > > as the ix86 family is concerned. > > > > Multilibs can be applied to implement multi-arch'ing, but actually > > multi-arching isn't tied to multilibs at all. > > OK, so we agree, we have a different definition of multilib than you > do. since all on this list use multilib in the "mixing arch" version > of the definition, please adjust, otherwise you only confuse us. :) Please don't speak for everybody unless you've asked each and everyone of us. I have the same definition as Ralf, for example. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Fri Apr 27 14:50:10 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 16:50:10 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070426171648.GB7127@neu.nirvana> References: <20070425173942.GU11831@neu.nirvana> <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> Message-ID: <20070427145010.GE20840@ryvius.pekin.waw.pl> On Thursday, 26 April 2007 at 19:16, Axel Thimm wrote: > On Thu, Apr 26, 2007 at 01:07:43PM +0100, David Woodhouse wrote: > > On Thu, 2007-04-26 at 13:13 +0200, Axel Thimm wrote: > > > Which is only needed once you start allowing (in your concept) files > > > of one "color" to be overwritable by another. > > > > Allowing that was always a mistake. It needs to die. > > > > > > 'punched install/remove holes'? > > > > > > See a prvious mail, but for the sake of context: > > > > > > yum install foo.i386 > > > yum install foo.x86_64 > > > > Error. Files from foo.x86_64 conflict with files from foo.i386. > > > > > yum remove foo.x86_64 > > > > Error. foo.x86_64 is not installed. > > > > > rpm -V foo > > > > Works fine. > > God, I hate it when people trim away the important parts. Aow you > assume again your model of "review everything once again, we'll split > off all bins by F10-F11", but I'm still in this year, and want Fedora > to do something more then rereviewing all its specfiles several times > a year. ... by introducing the abomination of bin64? Over my dead body. This is wrong, breaks all kinds of things and confuses not only users, but administrators as well. If you want to do multiarching, go the gentoo/debian way and use a chroot. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pertusus at free.fr Fri Apr 27 14:55:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 27 Apr 2007 16:55:17 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427145010.GE20840@ryvius.pekin.waw.pl> References: <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> Message-ID: <20070427145517.GB3031@free.fr> On Fri, Apr 27, 2007 at 04:50:10PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > ... by introducing the abomination of bin64? Over my dead body. This is > wrong, breaks all kinds of things and confuses not only users, but > administrators as well. If you want to do multiarching, go the > gentoo/debian way and use a chroot. Although I don't like bin64, I'd prefer bin32, it seems to me that the current multilib handling is quite confusing. It seems to me that having a directory per arch is less confusing than having both arches binaries in bin. lib64 and lib is confusing then too? doing a chroot is possible, but here the objective is to have both in the same root, which is an interesting goal. Having a root for each arch is much easier to achieve, but also less interesting. -- Pat From stickster at gmail.com Fri Apr 27 15:06:07 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 27 Apr 2007 11:06:07 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177612328.14131.4.camel@cutter> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> <200704261348.10615.jkeating@redhat.com> <20070426180151.GC3756@nostromo.devel.redhat.com> <1177612328.14131.4.camel@cutter> Message-ID: <1177686367.4321.11.camel@localhost.localdomain> On Thu, 2007-04-26 at 14:32 -0400, seth vidal wrote: > On Thu, 2007-04-26 at 14:01 -0400, Bill Nottingham wrote: > > Jesse Keating (jkeating at redhat.com) said: > > > > Hannibal > > > > > > Oh man, I like this one. F9 could be another famous cannibal? > > > > I love it when a plan comes together. > > > > that was so _wrong_. I'm readying my vote for "Donner" for F8, which segues nicely to a selection of film directors (Kurosawa? Truffaut? ah, a personal sweet spot...) for F9. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Axel.Thimm at ATrpms.net Fri Apr 27 15:10:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 17:10:07 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177680019.2755.553.camel@pmac.infradead.org> References: <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> Message-ID: <20070427151007.GA3831@neu.nirvana> On Fri, Apr 27, 2007 at 02:20:19PM +0100, David Woodhouse wrote: > On Fri, 2007-04-27 at 14:13 +0200, Axel Thimm wrote: > > > there are 1286 32-bit binary packages. > > In today's rawhide of the upcoming merged F7 there are 6569, you > > already cut away 80% of the packages. You are not implying that we > > only fix 20% of the packages because they happen to be on the CD? > > > > Or that we constrain our analysis on only was has been cherry-picked > > for a spin and is know to be working multilib wise? > > No, this is _all_ the ppc32 packages in the ppc compose. > Although of course you're right that it doesn't include Extras. Hardly even Core. ppc for Core has 3076 32-bit packages, not 1286. > > Conveniently missing the *-devel packages. > > By omitting /usr/lib/*.so, you mean? OK, we can add that too if you want > to nitpick '^(/usr|)/lib/[^/]*.so(|\..*)$'). Then we need to remove a > bunch of false positives with just stuff like /usr/bin/pcre-config which > is a script not an executable, and we gain 21 more source packages, for > a total of 160 -- or 12%. No, these are not false positives: # grep -l lib64 /usr/bin/*-config | wc -l; ls /usr/bin/*-config | wc -l 43 89 This is on a typical FC6/x86_64 install maxed by click all in, not @everything, so it is a sample, but it indicates that half the *-config packages *are* architecture specific. > > OTOH you are missing all foo-config scripts that are in foo-devel and > > are arch specific, this outweights any false positives like the ones > > you describe. > > If those are arch-specific then they're broken, Well, anything that does not suit your model is tagged as broken and needs fixing. Maybe it is, maybe not, but the bin64 model does not care, it can live with both, w/o having us to fix all and everything before we can thinkn about multilib. > We can keep refining it all day, but I don't really see the point unless > we're actually going to start filing bugs against the ones which need > splitting. But there is no point in filling bugs against healthy packages. Just to follow your proposed model of conflicting sub-sub-packages? > So a more interesting statistic might be the number of binary packages > which weren't rebuilt between FC6 and FC7 -- which is about 47 judging > by the disttags. Well, since I did the math recently, I can tell you that this number is *very* bogus. Otherwise there wouldn't had been any dicussion at all about mass rebuilds. > > And you still remain with the problem of conflicting packages, > > There is no _problem_ with conflicting packages. There are only > conflicting packages, which you may not install simultaneously. Aha, and that's not a problem, huh? yum install foo.x86_64 foo.i386 [...] File boo from foo.x86_64 conflicts with file boo from foo.i386 [...] yum/smart/apt assume a *healthy* repo. Not one that will have transaction failures planned in. > > haven't solved even the pkgconfig issue or firefox like issues (or > > any other category-similar issues), > > Neither have I solved world hunger. Good, but bin64 has solved the two above, so it's a better solution. > These are unrelated issues which as far as I can tell your solution > doesn't solve either. World hunger? Giving the savings in resources perhaps every devlopers will donate a penny for each saved hour and we'll solve that, too. > If you have to have your $PATH set to /bin64 or /bin according to > whether you're building for 64-bit or 32-bit, to make sure you pick > up the right foo-config or pkgconfig .pc files, then that's still > broken. Why, the developers just hits "goi386" and voila this xterm turned into a pure i386 xterm, where he can work just like on a pure i386 system. That's not broken, that's just great. > And I'm not sure _what_ you're referring to w.r.t firefox. Once we have > xulrunner (which can be installed for both arches simultaneously) and > separate firefox (which can not), that all works just fine. You install > plugins for one arch or the other, or both. There's no problem here. Yes, fix the issues one by one instead one and for all. You can also fix the pkgconfig issues, and libtool and whatnot, until the next one comes around the corner. That's why I wrote "category-similar issues", there will always be a "firefox" that you will need to run on i386, and "pkgconfig" build tools that will resist to be multilib'd. mplayer on certain codecs come to mind, which would also benefit from allowing both of them to install. mplayer foo fails? Then just try /usr/bin/mplayer foo? It just works w/o packaging mplayer-32 on x86_64? Great. So, it global-solving all in one, or micro-solving one by one. -- 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 buc at odusz.so-cdu.ru Fri Apr 27 15:11:00 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Fri, 27 Apr 2007 19:11:00 +0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070427145517.GB3031@free.fr> References: <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> Message-ID: <46321284.1030604@odu.neva.ru> Patrice Dumas wrote: > ... I'd prefer bin32 Oh, no!... /bin, /usr/bin, since the epoch... ~buc From Axel.Thimm at ATrpms.net Fri Apr 27 15:15:34 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 17:15:34 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427145010.GE20840@ryvius.pekin.waw.pl> References: <20070425174535.GB12287@ryvius.pekin.waw.pl> <1177534980.2755.265.camel@pmac.infradead.org> <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> Message-ID: <20070427151534.GB3831@neu.nirvana> On Fri, Apr 27, 2007 at 04:50:10PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 26 April 2007 at 19:16, Axel Thimm wrote: > > On Thu, Apr 26, 2007 at 01:07:43PM +0100, David Woodhouse wrote: > > > On Thu, 2007-04-26 at 13:13 +0200, Axel Thimm wrote: > > > > Which is only needed once you start allowing (in your concept) files > > > > of one "color" to be overwritable by another. > > > > > > Allowing that was always a mistake. It needs to die. > > > > > > > > 'punched install/remove holes'? > > > > > > > > See a prvious mail, but for the sake of context: > > > > > > > > yum install foo.i386 > > > > yum install foo.x86_64 > > > > > > Error. Files from foo.x86_64 conflict with files from foo.i386. > > > > > > > yum remove foo.x86_64 > > > > > > Error. foo.x86_64 is not installed. > > > > > > > rpm -V foo > > > > > > Works fine. > > > > God, I hate it when people trim away the important parts. Aow you > > assume again your model of "review everything once again, we'll split > > off all bins by F10-F11", but I'm still in this year, and want Fedora > > to do something more then rereviewing all its specfiles several times > > a year. > > ... by introducing the abomination of bin64? Over my dead body. Let's hope not. :) > This is wrong, breaks all kinds of things and confuses not only > users, but administrators as well. Well, we've discussed what it could break which isn't really much. And the confusion will be rather less than the current multilib model. Did you ever try to explain to an non-multilib expert (but otherwise skilled person) how multilib and elf coloring works? Usually they think you are making a fool out of them. ;) > If you want to do multiarching, go the gentoo/debian way and use a > chroot. You know what? I agree 101%. I just want to see this multilib breakage go away. But I don't think that will happen (e.g. replacing all the multilib stuff with plain and simple chroots) -- 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 27 15:14:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 27 Apr 2007 17:14:04 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <46321284.1030604@odu.neva.ru> References: <20070426082418.GD23704@neu.nirvana> <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> Message-ID: <20070427151404.GC3031@free.fr> On Fri, Apr 27, 2007 at 07:11:00PM +0400, Dmitry Butskoy wrote: > Patrice Dumas wrote: > >... I'd prefer bin32 > Oh, no!... > > /bin, /usr/bin, since the epoch... More precisely, I mean /bin, /usr/bin for the primary arch, and /bin32, /usr/bin32 for the secondary arch (32 bits) on x86_64. And the reverse on ppc, /bin, /usr/bin for 32 bits and /bin64, /usr/bin64 for the secondary arch. On ix86 /bin, /usr/bin only. To be even more precise I prefer that solution to bin64 for 64 bits and bin for 32 bits irrespective of the primary arch. One issue, though is that it is inconsistent with lib/lib64. -- Pat From blizzard at redhat.com Fri Apr 27 12:34:15 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 27 Apr 2007 08:34:15 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46311585.20204@redhat.com> References: <46311585.20204@redhat.com> Message-ID: <1177677255.25112.3.camel@localhost.localdomain> On Thu, 2007-04-26 at 17:11 -0400, Christopher Aillon wrote: > Peter Lemenkov wrote: > > Hello All! > > I found another one thing that was made unpractically. We got > > langpacks for 40 different languages that occupies ~12 MBytes from 43 > > Mbytes. This situatuin is drastically dioffers fron one with > > OpenOffice.org whose langpacks are not shipped with main app. > > > > I think that it would be reasonable to split firefox into main > > application package and many language packs. > > On my system right now, /usr/share/locale takes up 373MB, dwarfing > whatever Firefox uses. Splitting out Firefox's langpacks won't solve > your problem. Also, as long as the files are marked with %{lang} (working from memory here, can't remember if that's right) then the languages you don't want installed won't be when you install the rpm. You'll still get to download them, but that's a different issue. --Chris From blizzard at redhat.com Fri Apr 27 12:37:57 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 27 Apr 2007 08:37:57 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <20070426174421.GB3756@nostromo.devel.redhat.com> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> Message-ID: <1177677477.25112.6.camel@localhost.localdomain> On Thu, 2007-04-26 at 13:44 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > Fill in your suggestion for the blanks. Cannot link to Zod in the > > same way that Zod is linked to Bordeaux. > > > > Suggestions will be ran through the legal queue and an election will happen > > for Fedora contributors to pick the next Fedora name. > > Bordeaux -> Zod was DC universe characters. Which pretty much takes out > all the direct Superman references. > > So, other things. Zod is: > > - a character played by Terence Stamp > > - he's played other characters named 'Fish', 'Stick', 'Siegfried', > 'The Limey' > > - a General > > - Sherman, Patton, Hannibal, Lee, Orlov, Grevious, and many many many > many others - A ruler of men (not a leader!) - You could pick all kinds of polarizing names here :) - A man who dressed in all black (Cash?) --Chris From blizzard at redhat.com Fri Apr 27 12:39:43 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 27 Apr 2007 08:39:43 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261420.40331.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <1177610228.2745.21.camel@localhost.localdomain> <200704261420.40331.jkeating@redhat.com> Message-ID: <1177677583.25112.7.camel@localhost.localdomain> On Thu, 2007-04-26 at 14:20 -0400, Jesse Keating wrote: > On Thursday 26 April 2007 13:57:08 Adam Jackson wrote: > > Scorpio. Hank Scorpio in particular. Cartoon supervillians. > > I think that's a little too close to the Bordeaux -> Zod link. This is brainstorming! Stop trying to contract the conversation! (See also: Adam's mail you head made of meanie.) --Chris From blizzard at redhat.com Fri Apr 27 12:40:50 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 27 Apr 2007 08:40:50 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <20070426215251.GB18327@devserv.devel.redhat.com> References: <200704261322.01077.jkeating@redhat.com> <4630F6BE.9060507@redhat.com> <20070426215251.GB18327@devserv.devel.redhat.com> Message-ID: <1177677650.25112.9.camel@localhost.localdomain> On Thu, 2007-04-26 at 17:52 -0400, Alan Cox wrote: > On Thu, Apr 26, 2007 at 03:00:14PM -0400, Christopher Aillon wrote: > > 'Metropolis' (as does this) > > 'Hannibal' (also ties in as a General) > > 'Pendragon' > > Works for me. Especially Metropolis Metropolis has > 1 link here and fits our current theme. +1 --Chris From blizzard at redhat.com Fri Apr 27 16:22:52 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 27 Apr 2007 12:22:52 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46320C6C.7090803@hhs.nl> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> Message-ID: <1177690972.26176.14.camel@localhost.localdomain> On Fri, 2007-04-27 at 16:45 +0200, Hans de Goede wrote: > Matthias Clasen wrote: > > On Fri, 2007-04-27 at 08:14 +0400, Peter Lemenkov wrote: > >>> On my system right now, /usr/share/locale takes up 373MB, dwarfing > >>> whatever Firefox uses. Splitting out Firefox's langpacks won't solve > >>> your problem. > >> Does that the reason not to splitting Firefox? I think it's only the > >> evidence that someone doesn't know something about macros in rpm > >> configs. ) > >> > >> Take a look at %_install_langs macro - we can control installing > >> langpacks using it but not in case of firefox. > > > > So, this is just a request to add proper %lang annotations to the > > firefox file lists ? > > > > Yes and no, Peter's original request really was for seperate (sub) packages. > But Peter's problem can be solved too (and probably better) by adding proper > %lang annotations to the firefox file lists. This all AFAIK. > There used to be proper %lang attributes in the spec file way-back-when. Are they not there anymore? --Chris From alan at redhat.com Fri Apr 27 16:33:44 2007 From: alan at redhat.com (Alan Cox) Date: Fri, 27 Apr 2007 12:33:44 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177677477.25112.6.camel@localhost.localdomain> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> <1177677477.25112.6.camel@localhost.localdomain> Message-ID: <20070427163344.GA2508@devserv.devel.redhat.com> On Fri, Apr 27, 2007 at 08:37:57AM -0400, Christopher Blizzard wrote: > > - a General > > > > - Sherman, Patton, Hannibal, Lee, Orlov, Grevious, and many many many > > many others > > > - A ruler of men (not a leader!) For a general I'd have to suggest we call it "Monty" as with extras merged Fedora is now "the full monty" Alan From dwmw2 at infradead.org Fri Apr 27 16:35:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 Apr 2007 17:35:03 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427151007.GA3831@neu.nirvana> References: <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> Message-ID: <1177691703.2755.616.camel@pmac.infradead.org> On Fri, 2007-04-27 at 17:10 +0200, Axel Thimm wrote: > On Fri, Apr 27, 2007 at 02:20:19PM +0100, David Woodhouse wrote: > > On Fri, 2007-04-27 at 14:13 +0200, Axel Thimm wrote: > > > > there are 1286 32-bit binary packages. > > > > In today's rawhide of the upcoming merged F7 there are 6569, you > > > already cut away 80% of the packages. You are not implying that we > > > only fix 20% of the packages because they happen to be on the CD? > > > > > > Or that we constrain our analysis on only was has been cherry-picked > > > for a spin and is know to be working multilib wise? > > > > No, this is _all_ the ppc32 packages in the ppc compose. > > Although of course you're right that it doesn't include Extras. > > Hardly even Core. ppc for Core has 3076 32-bit packages, not 1286. Not on my planet. devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ ls *.ppc.rpm | wc -l 1286 But still, you're arguing over a pointless detail. I already _accepted_ your revised estimate of 14%, which was far closer to my original estimate of 10-20% than it was to your previous nonsense of "almost all specfiles". > > > OTOH you are missing all foo-config scripts that are in foo-devel and > > > are arch specific, this outweights any false positives like the ones > > > you describe. > > > > If those are arch-specific then they're broken, > > And your solution doesn't help there either, because you still pick > > up the first one on $PATH instead of the _right_ one according to > > what you're compiling for. > Well, anything that does not suit your model is tagged as broken and > needs fixing. Maybe it is, maybe not, but the bin64 model does not > care, it can live with both, w/o having us to fix all and everything > before we can thinkn about multilib. If they are arch-specific then they are broken in Fedora 7 as shipped, and will remain broken even with your proposed model, as I said above (actually you'd conveniently elided it, but I put it back). > > We can keep refining it all day, but I don't really see the point unless > > we're actually going to start filing bugs against the ones which need > > splitting. > > But there is no point in filling bugs against healthy packages. Just > to follow your proposed model of conflicting sub-sub-packages? > > > So a more interesting statistic might be the number of binary packages > > which weren't rebuilt between FC6 and FC7 -- which is about 47 judging > > by the disttags. > > Well, since I did the math recently, I can tell you that this number > is *very* bogus. Otherwise there wouldn't had been any dicussion at > all about mass rebuilds. Again, not in my world. devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ ls *.fc6.ppc.rpm | wc -l 49 > > > And you still remain with the problem of conflicting packages, > > > > There is no _problem_ with conflicting packages. There are only > > conflicting packages, which you may not install simultaneously. > > Aha, and that's not a problem, huh? Correct. It's not a problem. > yum install foo.x86_64 foo.i386 > [...] > File boo from foo.x86_64 conflicts with file boo from foo.i386 > [...] Yep, that's expected. Don't Do That Then?. > yum/smart/apt assume a *healthy* repo. Not one that will have > transaction failures planned in. The repo is healthy; the user asked for something bogus. If I try to install glibc.ppc64 on my 32-bit laptop I get a failure too. Is that not "healthy" either? > > > haven't solved even the pkgconfig issue or firefox like issues (or > > > any other category-similar issues), > > > > Neither have I solved world hunger. These are unrelated issues which as > > far as I can tell your solution doesn't solve either. If you have to > > have your $PATH set to /bin64 or /bin according to whether you're > > building for 64-bit or 32-bit, to make sure you pick up the right > > foo-config or pkgconfig .pc files, then that's still broken. > > Good, but bin64 has solved the two above, so it's a better solution. Ok, so you're claiming that you _do_ solve the first issue just by setting $PATH? And that nobody will ever be using /bin/$FOO in their scripts &c, so that'll always work? And that'll work for stuff which tries to use dlopen() of stuff in /usr/lib (or is it /usr/lib32?) too? And which runs its own helper binaries from /usr/libexec without looking at $PATH? If you want to make that work, it's going to take a whole lot more work than just splitting a few packages into libraries vs. binaries. And then you're claiming that your solution also fixes the nebulous 'firefox issue' which you then failed to actually identify when asked for details? *plonk* > Yes, fix the issues one by one instead one and for all. Alternatively, we can _fix_ the issues rather than trying to paper over them and introducing new problems. > mplayer on certain codecs come to mind, which would also benefit from > allowing both of them to install. mplayer foo fails? Then just try > /usr/bin/mplayer foo? It just works w/o packaging mplayer-32 on > x86_64? Great. This is solved with our existing setup, by just installing the 32-bit mplayer and not the 64-bit one. > So, it global-solving all in one, or micro-solving one by one. Your 'solution' has its own issues, and you're still massively overestimating the amount of work it would take to split the packaging, while conveniently ignoring the amount of work it would take to make /bin32 work. Why don't you come back when the LSB has seen the light and accepted your proposal and when upstream software isn't all going to break? Now we've talked you down from your totally bogus "almost all specfiles" to a more sensible 14% or so, we might observe that if I'd just got on with it instead of wasting my time on you, I'd probably have done a quarter of the Core packages by now. And if you'd been doing it too instead of masturbating over the precise numbers and misquoting the rest of the discussion, we might even be half-way there. Even if your alternative _wasn't_ going to take any work, I'm just not interested in cutting corners because the alternative takes too much short-term work. That's the mistake we've made with our multilib support all along, and it's time to stop. -- dwmw2 From dominik at greysector.net Fri Apr 27 16:42:20 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 18:42:20 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427002608.GC21691@neu.nirvana> References: <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> Message-ID: <20070427164220.GF20840@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 02:26, Axel Thimm wrote: > On Thu, Apr 26, 2007 at 10:39:23PM +0100, David Woodhouse wrote: > > On Thu, 2007-04-26 at 21:30 +0200, Axel Thimm wrote: [...] > > > The "David Woodhouse improved multilib design that requires bin > > > suppackage splits for every bin carrying package" tries to circumvent > > > this problem by spliting out the bin contents in subpackages. But this > > > is another bad short-term decision, as it > > > > > > o forces us to revisit every bin carrying package out there speding > > > tons of resources better used elsewhere > > > > You overestimate the effort involved. It can be checked automatically, > > and when conflicts are found, the fix is simple. > > Ok, a hands on example to demonstrate that this is not so: > > %build > blah > > %install > blub > > %files > %{_bindir}/foo > %{_datadir}/foo > > %files mon > %{_sbindir}/foo-mon > %{_localstatdir}/lib/foo-mon > > %files devel > %{_bindir}/foo-config > %{_includedir} > > So you want to sub-subpackage all three subpackages to a total of 6 > subpackages with interesting set of intra-dependencies and you even > claim that this will happen automatically w/o a human going through > the specfiles? So let perl and sed automatically mungle the specfiles? > Or what other automatic management would you apply? If a package > required foo, does it now require foo-bin or foo ("the rest")? You > can't know w/o reviewing this. Does foo-bin require foo ("the rest") > or foo ("the rest") require foo-bin? You will find out that both is > needed, so you will have tons of circular dependencies. No. This package is not multilib-able. Period. It's either one arch, or another. It has no files in %{_libdir}. [...] > > > In comparison the bin64 solution costs us almost nothing: > > > o most packages will rebuild in unattended mode > > > o breakage of false bindir will be detected during the build itself > > > o You can use two cleanly distinct repos with the depsolver tools of > > > today, no need to add any funny support anywhere > > > o You fix an FHS violation, in exchange for another, which just brings > > > us bad to balance > > > o The FHS has already considered this (thanks to the Debain folks) and > > > is waiting for distros to actually utter the demand to include it. > > > > It buys you the ability to install _both_ versions of the package > > simultaneously, but you can't easily choose which version to prefer for > > a _specific_ package -- you can only set bin64 before or after bin in > > $PATH, which affects _all_ installed programs. > > Always before. If you install both the default invocation makes bin64 > win. The other arch is the legacy arch (at least for i386/x86_64), so > it shouldn't default itself to higher priority. Why always? ppc and sparc prefer 32bit binaries because of serious speed difference. [...] > > Unless you split the packages out so that you can have libraries > > installed for the secondary arch without having to have the > > binaries, I suppose? :) > > That does not make sense at all. Because now you can't choose at all > at runtime, you need to uninstall and install the other version, > that's hardly a better way than to simply call a prefix to the > command, just compare: > > bin64: > > yum install firefox.i386 firefox.x86_64 > firefox -> 64 bit firefox, damn that flash website doesn't work > goi386 firefox -> 32 bit firefox, view that ugly flash site > firefox -> back to sane 64 bits > > Dave's multilib2: > > yum install firefox-bin.x86_64 firefox-libs.x86_64 firefox-libs.i386 > firefox -> 64 bit firefox, damn that flash website doesn't work > yum remove firefox-bin (wait) > yum install firefox-bin.i386 (wait more, needs to be always online or > have big yum cache) > firefox -> 32 bit firefox, view that ugly flash site > yum remove firefox-bin (wait) > yum install firefox-bin.x86_64 (wait more, needs to be always online or > have big yum cache) You're talking multiarch again. We don't want to have both 32bit and 64bit binaries installed! I know diskspace is cheap, but the user doesn't need two binaries for each application. You install either 32bit or 64bit version and use that. Why switch at all? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Fri Apr 27 16:48:55 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 18:48:55 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177691703.2755.616.camel@pmac.infradead.org> References: <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> Message-ID: <20070427164855.GG20840@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 18:35, David Woodhouse wrote: > On Fri, 2007-04-27 at 17:10 +0200, Axel Thimm wrote: > > > mplayer on certain codecs come to mind, which would also benefit from > > allowing both of them to install. mplayer foo fails? Then just try > > /usr/bin/mplayer foo? It just works w/o packaging mplayer-32 on > > x86_64? Great. > > This is solved with our existing setup, by just installing the 32-bit > mplayer and not the 64-bit one. And there's very little reason to install the 32bit one, unless you absolutely need to play Windows Media Audio v3 or Windows Media Video v2. The first one hasn't been reverse-engineered yet and the other is not fully implemented (J-frames are not decoded properly). Oh, and maybe Intel Indeo4/5, too, but that's it. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Fri Apr 27 16:57:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 18:57:04 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427164220.GF20840@ryvius.pekin.waw.pl> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> Message-ID: <20070427165704.GC3831@neu.nirvana> On Fri, Apr 27, 2007 at 06:42:20PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 27 April 2007 at 02:26, Axel Thimm wrote: > > On Thu, Apr 26, 2007 at 10:39:23PM +0100, David Woodhouse wrote: > > > On Thu, 2007-04-26 at 21:30 +0200, Axel Thimm wrote: > [...] > > > > The "David Woodhouse improved multilib design that requires bin > > > > suppackage splits for every bin carrying package" tries to circumvent > > > > this problem by spliting out the bin contents in subpackages. But this > > > > is another bad short-term decision, as it > > > > > > > > o forces us to revisit every bin carrying package out there speding > > > > tons of resources better used elsewhere > > > > > > You overestimate the effort involved. It can be checked automatically, > > > and when conflicts are found, the fix is simple. > > > > Ok, a hands on example to demonstrate that this is not so: > > > > %build > > blah > > > > %install > > blub > > > > %files > > %{_bindir}/foo > > %{_datadir}/foo > > > > %files mon > > %{_sbindir}/foo-mon > > %{_localstatdir}/lib/foo-mon > > > > %files devel > > %{_bindir}/foo-config > > %{_includedir} > > > > So you want to sub-subpackage all three subpackages to a total of 6 > > subpackages with interesting set of intra-dependencies and you even > > claim that this will happen automatically w/o a human going through > > the specfiles? So let perl and sed automatically mungle the specfiles? > > Or what other automatic management would you apply? If a package > > required foo, does it now require foo-bin or foo ("the rest")? You > > can't know w/o reviewing this. Does foo-bin require foo ("the rest") > > or foo ("the rest") require foo-bin? You will find out that both is > > needed, so you will have tons of circular dependencies. > > No. This package is not multilib-able. Period. It's either one arch, > or another. It has no files in %{_libdir}. Ah, "minor" forgotten detail. Just fill the blanks, with %{_libdir}/*.so.* and %{_libdir}/*.so. > > Always before. If you install both the default invocation makes bin64 > > win. The other arch is the legacy arch (at least for i386/x86_64), so > > it shouldn't default itself to higher priority. > > Why always? ppc and sparc prefer 32bit binaries because of serious > speed difference. That's what I wrote "at least for i386/x86_64", every current or future multiarch system will define its primary and secondary archs differently. > You're talking multiarch again. We don't want to have both 32bit > and 64bit binaries installed! I know diskspace is cheap, but the user > doesn't need two binaries for each application. He doesn't *have* to, but he may *want* to. The difference is that in the current model we have to choose for the user, and we seem to make the wrong choices, since every FC release has been redifining what we allow the user to do. So just let them have the full thing, so they can deploy whatever multi-scenario they need and we don't have to care about stuff beginning with multi anymore. > You install either 32bit or 64bit version and use that. Why switch > at all? So you never wanted to check how mplayer on i386/x86_64 behave? FWIW most users install mplayer.x86_64 and when they hit on something that doesn't work they are desperate about getting the i386 version. Same for firefox until now. -- 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 Fri Apr 27 17:09:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Apr 2007 13:09:43 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177691703.2755.616.camel@pmac.infradead.org> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> Message-ID: <200704271309.43597.jkeating@redhat.com> On Friday 27 April 2007 12:35:03 David Woodhouse wrote: > > Hardly even Core. ppc for Core has 3076 32-bit packages, not 1286. > > Not on my planet. > > devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ > ls *.ppc.rpm | wc -l 1286 David, you're looking at the "Fedora" spin which is a subset of all the packages, some Core, some Extras. Axel is obviously looking at the full tree. -- 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 Fri Apr 27 17:32:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 19:32:15 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177691703.2755.616.camel@pmac.infradead.org> References: <20070427002608.GC21691@neu.nirvana> <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> Message-ID: <20070427173215.GD3831@neu.nirvana> On Fri, Apr 27, 2007 at 05:35:03PM +0100, David Woodhouse wrote: > On Fri, 2007-04-27 at 17:10 +0200, Axel Thimm wrote: > > On Fri, Apr 27, 2007 at 02:20:19PM +0100, David Woodhouse wrote: > > > On Fri, 2007-04-27 at 14:13 +0200, Axel Thimm wrote: > > > > > there are 1286 32-bit binary packages. > > > > > > In today's rawhide of the upcoming merged F7 there are 6569, you > > > > already cut away 80% of the packages. You are not implying that we > > > > only fix 20% of the packages because they happen to be on the CD? > > > > > > > > Or that we constrain our analysis on only was has been cherry-picked > > > > for a spin and is know to be working multilib wise? > > > > > > No, this is _all_ the ppc32 packages in the ppc compose. > > > Although of course you're right that it doesn't include Extras. > > > > Hardly even Core. ppc for Core has 3076 32-bit packages, not 1286. > > Not on my planet. Earth to planet David, earth to planet David! > devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ ls *.ppc.rpm | wc -l > 1286 # cd /storage/public/mirror/download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/os/Fedora; ls *.ppc.rpm | wc -l 3076 Are you really only after fixing the bits that are on CD? I'd like to stay a bit more global and do Core and Extras. > But still, you're arguing over a pointless detail. No, don't subvert statistics, your numbers are always based on your ppc compose. That's not the complete set of Fedora packages affected and not only it "doesn't include Extras", but "hardly even Core". So that's how at the end you get at 47 packages that need to be fixed instead of 606. Pointless detail? Well, whatever. > > > > OTOH you are missing all foo-config scripts that are in foo-devel and > > > > are arch specific, this outweights any false positives like the ones > > > > you describe. > > > > > > If those are arch-specific then they're broken, > > > And your solution doesn't help there either, because you still pick > > > up the first one on $PATH instead of the _right_ one according to > > > what you're compiling for. > > > Well, anything that does not suit your model is tagged as broken and > > needs fixing. Maybe it is, maybe not, but the bin64 model does not > > care, it can live with both, w/o having us to fix all and everything > > before we can thinkn about multilib. > > If they are arch-specific then they are broken in Fedora 7 as shipped, > and will remain broken even with your proposed model, as I said above > (actually you'd conveniently elided it, but I put it back). No, that's just not the case. /usr/bin64/foo-config gives me info for how the package is built under x86_64, /usr/bin/foo-config for i386. Not only could the paths diverge, but even parts like -DMMX may be different. Yep, separating foo-configs is the long term solution. So, no convenient elusion, but just a plain fact that shouldn't need more commenting (but obviously it did). > > > So a more interesting statistic might be the number of binary packages > > > which weren't rebuilt between FC6 and FC7 -- which is about 47 judging > > > by the disttags. > > > > Well, since I did the math recently, I can tell you that this number > > is *very* bogus. Otherwise there wouldn't had been any dicussion at > > all about mass rebuilds. > > Again, not in my world. > > devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ ls *.fc6.ppc.rpm | wc -l > 49 In our world this number is more like 759. > > > > And you still remain with the problem of conflicting packages, > > > > > > There is no _problem_ with conflicting packages. There are only > > > conflicting packages, which you may not install simultaneously. > > > > Aha, and that's not a problem, huh? > > Correct. It's not a problem. > > > yum install foo.x86_64 foo.i386 > > [...] > > File boo from foo.x86_64 conflicts with file boo from foo.i386 > > [...] > > Yep, that's expected. Don't Do That Then?. It is expected to have a broken repo? yum defines this as a broken repo, the packaging guidelines define this a broken behaviour (for good reasons, there should not be file level conflicts, but package level conflicts, and no, rpm does not support cross-arch conflicts) So, what you prosose is a messier situation than the current multilib one. No, thanks. > > yum/smart/apt assume a *healthy* repo. Not one that will have > > transaction failures planned in. > > The repo is healthy; the user asked for something bogus. Sure, the error is always in front of the keyboard. Convenient long-term solution. > > > > haven't solved even the pkgconfig issue or firefox like issues (or > > > > any other category-similar issues), > > > > > > Neither have I solved world hunger. These are unrelated issues which as > > > far as I can tell your solution doesn't solve either. If you have to > > > have your $PATH set to /bin64 or /bin according to whether you're > > > building for 64-bit or 32-bit, to make sure you pick up the right > > > foo-config or pkgconfig .pc files, then that's still broken. > > > > Good, but bin64 has solved the two above, so it's a better solution. > > Ok, so you're claiming that you _do_ solve the first issue just by > setting $PATH? And that nobody will ever be using /bin/$FOO in their > scripts &c, so that'll always work? I did write that simply setting _bindir will not be enough, but it will cover most packages. > And that'll work for stuff which tries to use dlopen() of stuff > in /usr/lib (or is it /usr/lib32?) too? That does not change from today's lib/lib64 split. > And which runs its own helper binaries from /usr/libexec without > looking at $PATH? You missed the part about libexec, which BTW is another reason for going bin64. We can finally move libexec to libdir as the FHS mandates (while violating the FHS again, so FHS-wise it is a stalemate). libexec today is used as bindir, which means file munging and punchholes. > If you want to make that work, it's going to take a whole lot more work > than just splitting a few packages into libraries vs. binaries. > > And then you're claiming that your solution also fixes the nebulous > 'firefox issue' which you then failed to actually identify when asked > for details? Are you reading or just ranting? Of course I answered on the firefox bits. > *plonk* Get out of the bin, please. > > Yes, fix the issues one by one instead one and for all. > > Alternatively, we can _fix_ the issues rather than trying to paper over > them and introducing new problems. I agree, so why do you suggest to have bin sub-subpackages that will be file-conflicting? > > mplayer on certain codecs come to mind, which would also benefit from > > allowing both of them to install. mplayer foo fails? Then just try > > /usr/bin/mplayer foo? It just works w/o packaging mplayer-32 on > > x86_64? Great. > > This is solved with our existing setup, by just installing the 32-bit > mplayer and not the 64-bit one. # yum install mplayer.i386 file /usr/bin/mplayer from mplayer.i386 conflicts with file /usr/bin/mplayer from installed mplayer.x86_64 # yum remove mplayer mplayer is needed by ... # rpm -e --nodeps mplayer # yum install mplayer.i386 # mplayer foo # yum install mplayer.x86_64 file /usr/bin/mplayer from mplayer.x86_64 conflicts with file /usr/bin/mplayer from installed mplayer.i386 # rpm -e --nodeps mplayer.x86_64; yum install mplayer Sorry, you are offline, please try later The better solution: # yum install mplayer.i386 # goi386 mplayer foo # mplayer foo > > So, it global-solving all in one, or micro-solving one by one. > > Your 'solution' has its own issues, and you're still massively > overestimating the amount of work it would take to split the packaging, Well, our estimates are a factor of 15 (e.g. 759/49) apart, since on your planet there is only the ppc compose, but you're ignoring the rest of Core and all of Extras. But I do think the the Fedora project will not drop half of Core and Extras to accomodate your planet. > while conveniently ignoring the amount of work it would take to > make /bin32 work. Why don't you come back when the LSB has seen the > light and accepted your proposal and when upstream software isn't all > going to break? The LSB, or better said the FHS are ready to give green light the moment some distro seriously inquires, check the ongoing multiarch discussions there. > Now we've talked you down from your totally bogus "almost all specfiles" > to a more sensible 14% or so, OK, so I was a factor 7 wrong, while you are a factor 15 apart? > we might observe that if I'd just got on > with it instead of wasting my time on you, I'd probably have done a > quarter of the Core packages by now. Cool, please finish all by tomorrow, so we can see yum break. I'm sure the yum developers will be glad for that. > And if you'd been doing it too instead of masturbating Sorry, other than foobaring the numbers to your convenience you used vulgar talk, that has no place on this list, back to the bin! *PLONK* -- 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 ed at eh3.com Fri Apr 27 17:34:36 2007 From: ed at eh3.com (Ed Hill) Date: Fri, 27 Apr 2007 13:34:36 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427164220.GF20840@ryvius.pekin.waw.pl> References: <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> Message-ID: <20070427133436.6960960b@daggett> On Fri, 27 Apr 2007 18:42:20 +0200 "Dominik 'Rathann' Mierzejewski" wrote: > > You're talking multiarch again. We don't want to have both 32bit > and 64bit binaries installed! I know diskspace is cheap, but the user > doesn't need two binaries for each application. > > You install either 32bit or 64bit version and use that. Why switch > at all? Sometimes folks *do* want both. And who are you to dictate that everyone else must install just one or just the other globally? What if, on a multi-user system, USER_A wants firefox.i386 and USER_B wants firefox.x86_64 ? There are no technical reasons why it can't be done so why try to impose some artificial (and IMO self-defeating) barriers? Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Fri Apr 27 17:36:56 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 Apr 2007 18:36:56 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <200704271309.43597.jkeating@redhat.com> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> Message-ID: <1177695416.2755.624.camel@pmac.infradead.org> On Fri, 2007-04-27 at 13:09 -0400, Jesse Keating wrote: > On Friday 27 April 2007 12:35:03 David Woodhouse wrote: > > > Hardly even Core. ppc for Core has 3076 32-bit packages, not 1286. > > > > Not on my planet. > > > > devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ > > ls *.ppc.rpm | wc -l 1286 > > David, you're looking at the "Fedora" spin which is a subset of all the > packages, some Core, some Extras. Axel is obviously looking at the full > tree. Ah, thanks. If I look at my rawhide mirror, that helps me get slightly closer to his inflated numbers -- but still I only get to 1974 files matching *.ppc.rpm. There are only 3004 files in total. Perhaps he has a slightly fresher mirror, _and_ we've added seventy-odd packages recently, _and_ he was listing all files instead of only the 32-bit packages. He conveniently didn't show what he did to count them, of course. But it doesn't matter -- I've already accepted his estimate of 14%, which is fairly much in line with my own estimate and dramatically less than his original "almost all specfiles" nonsense. And even that doesn't matter, because if it's the right thing to do then we shouldn't care how many packages need to be touched. It's not as if it's hard to do. -- dwmw2 From dominik at greysector.net Fri Apr 27 17:57:11 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 19:57:11 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427133436.6960960b@daggett> References: <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> Message-ID: <20070427175711.GA23643@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 19:34, Ed Hill wrote: > On Fri, 27 Apr 2007 18:42:20 +0200 "Dominik 'Rathann' Mierzejewski" wrote: > > > > You're talking multiarch again. We don't want to have both 32bit > > and 64bit binaries installed! I know diskspace is cheap, but the user > > doesn't need two binaries for each application. > > > > You install either 32bit or 64bit version and use that. Why switch > > at all? > > > Sometimes folks *do* want both. > > And who are you to dictate that everyone else must install just one or > just the other globally? What if, on a multi-user system, USER_A wants > firefox.i386 and USER_B wants firefox.x86_64 ? They can't have it both ways currently. Well, not in this example, because firefox installs its binaries in %{_libdir}, but generally, no. > There are no technical > reasons why it can't be done so why try to impose some artificial (and > IMO self-defeating) barriers? Because that's what we've been doing for years? If you want to start talking about multiarching, we can do that, too, but the topic at hand is different. Yes, there's no technical reason for not installing both 32bit and 64bit version at the same time, but it means we'd need to go down the bin{32,64} path and that's a major change which I'm firmly against. So let's keep the discussion to the point, shall we? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From stickster at gmail.com Fri Apr 27 18:01:18 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 27 Apr 2007 14:01:18 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177677650.25112.9.camel@localhost.localdomain> References: <200704261322.01077.jkeating@redhat.com> <4630F6BE.9060507@redhat.com> <20070426215251.GB18327@devserv.devel.redhat.com> <1177677650.25112.9.camel@localhost.localdomain> Message-ID: <1177696878.32569.4.camel@localhost.localdomain> On Fri, 2007-04-27 at 08:40 -0400, Christopher Blizzard wrote: > On Thu, 2007-04-26 at 17:52 -0400, Alan Cox wrote: > > On Thu, Apr 26, 2007 at 03:00:14PM -0400, Christopher Aillon wrote: > > > 'Metropolis' (as does this) > > > 'Hannibal' (also ties in as a General) > > > 'Pendragon' > > > > Works for me. Especially Metropolis > > Metropolis has > 1 link here and fits our current theme. +1 Crap, the >1 link thing. /me crumples earlier post. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dominik at greysector.net Fri Apr 27 18:03:11 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 20:03:11 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427165704.GC3831@neu.nirvana> References: <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427165704.GC3831@neu.nirvana> Message-ID: <20070427180311.GB23643@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 18:57, Axel Thimm wrote: > On Fri, Apr 27, 2007 at 06:42:20PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 27 April 2007 at 02:26, Axel Thimm wrote: > > > On Thu, Apr 26, 2007 at 10:39:23PM +0100, David Woodhouse wrote: > > > > On Thu, 2007-04-26 at 21:30 +0200, Axel Thimm wrote: > > [...] > > > > > The "David Woodhouse improved multilib design that requires bin > > > > > suppackage splits for every bin carrying package" tries to circumvent > > > > > this problem by spliting out the bin contents in subpackages. But this > > > > > is another bad short-term decision, as it > > > > > > > > > > o forces us to revisit every bin carrying package out there speding > > > > > tons of resources better used elsewhere > > > > > > > > You overestimate the effort involved. It can be checked automatically, > > > > and when conflicts are found, the fix is simple. > > > > > > Ok, a hands on example to demonstrate that this is not so: > > > > > > %build > > > blah > > > > > > %install > > > blub > > > > > > %files > > > %{_bindir}/foo > > > %{_datadir}/foo > > > > > > %files mon > > > %{_sbindir}/foo-mon > > > %{_localstatdir}/lib/foo-mon > > > > > > %files devel > > > %{_bindir}/foo-config > > > %{_includedir} > > > > > > So you want to sub-subpackage all three subpackages to a total of 6 > > > subpackages with interesting set of intra-dependencies and you even > > > claim that this will happen automatically w/o a human going through > > > the specfiles? So let perl and sed automatically mungle the specfiles? > > > Or what other automatic management would you apply? If a package > > > required foo, does it now require foo-bin or foo ("the rest")? You > > > can't know w/o reviewing this. Does foo-bin require foo ("the rest") > > > or foo ("the rest") require foo-bin? You will find out that both is > > > needed, so you will have tons of circular dependencies. > > > > No. This package is not multilib-able. Period. It's either one arch, > > or another. It has no files in %{_libdir}. > > Ah, "minor" forgotten detail. Just fill the blanks, with > %{_libdir}/*.so.* and %{_libdir}/*.so. In that case, you can have both 32bit and 64bit -libs installed (because they don't conflict), but only one devel and one main package (because they do conflict). That makes 4 packages from your example, not 6. I don't know where your -bin subpackage came from, but it's clearly not what David or I are proposing. > > > Always before. If you install both the default invocation makes bin64 > > > win. The other arch is the legacy arch (at least for i386/x86_64), so > > > it shouldn't default itself to higher priority. > > > > Why always? ppc and sparc prefer 32bit binaries because of serious > > speed difference. > > That's what I wrote "at least for i386/x86_64", every current or > future multiarch system will define its primary and secondary archs > differently. > > > You're talking multiarch again. We don't want to have both 32bit > > and 64bit binaries installed! I know diskspace is cheap, but the user > > doesn't need two binaries for each application. > > He doesn't *have* to, but he may *want* to. > > The difference is that in the current model we have to choose for the > user, and we seem to make the wrong choices, since every FC release > has been redifining what we allow the user to do. So just let them > have the full thing, so they can deploy whatever multi-scenario they > need and we don't have to care about stuff beginning with multi > anymore. So now you're talking about full multiarch support. We can talk about that, but that's a MAJOR change and needs a separate evaluation. > > You install either 32bit or 64bit version and use that. Why switch > > at all? > > So you never wanted to check how mplayer on i386/x86_64 behave? FWIW > most users install mplayer.x86_64 and when they hit on something that > doesn't work they are desperate about getting the i386 version. Same > for firefox until now. yum remove mplayer && yum --enablerepo=\*i386 install mplayer. What's the problem? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jkeating at redhat.com Fri Apr 27 17:58:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 27 Apr 2007 13:58:20 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177696878.32569.4.camel@localhost.localdomain> References: <200704261322.01077.jkeating@redhat.com> <1177677650.25112.9.camel@localhost.localdomain> <1177696878.32569.4.camel@localhost.localdomain> Message-ID: <200704271358.23727.jkeating@redhat.com> On Friday 27 April 2007 14:01:18 Paul W. Frields wrote: > Crap, the >1 link thing. ?/me crumples earlier post. IIRC >1 isn't a requirement. Just it has to have a _different_ link than the link used last time. -- 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 caillon at redhat.com Fri Apr 27 18:04:56 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 27 Apr 2007 14:04:56 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704271358.23727.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <1177677650.25112.9.camel@localhost.localdomain> <1177696878.32569.4.camel@localhost.localdomain> <200704271358.23727.jkeating@redhat.com> Message-ID: <46323B48.1060906@redhat.com> Jesse Keating wrote: > On Friday 27 April 2007 14:01:18 Paul W. Frields wrote: >> Crap, the >1 link thing. /me crumples earlier post. > > IIRC >1 isn't a requirement. Just it has to have a _different_ link than the > link used last time. But >1 is clearly more bettar. :P From Axel.Thimm at ATrpms.net Fri Apr 27 18:08:42 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 20:08:42 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427175711.GA23643@ryvius.pekin.waw.pl> References: <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> Message-ID: <20070427180842.GE3831@neu.nirvana> On Fri, Apr 27, 2007 at 07:57:11PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 27 April 2007 at 19:34, Ed Hill wrote: > > There are no technical reasons why it can't be done so why try to > > impose some artificial (and IMO self-defeating) barriers? > > Because that's what we've been doing for years? But honestly, that really isn't a reason for not fixing something? > If you want to start talking about multiarching, we can do that, > too, but the topic at hand is different. One way to solve all multilib problems is to scratch multilib and use multiarch, e.g. avoid the arch-overwriting mechanism we currently use, so I wouldn't say we're off-topic in considering multi-arch. > Yes, there's no technical reason for not installing both 32bit and 64bit > version at the same time, but it means we'd need to go down the bin{32,64} > path and that's a major change which I'm firmly against. OK, but why? Any suggestions need to be considered based on benefits and drawbacks. If at the end there are more benefits that drawback one chooses that, but w/o analysing it and blocking something from the start you may miss important opportunities. > So let's keep the discussion to the point, shall we? -- 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 Fri Apr 27 18:13:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 20:13:11 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427180311.GB23643@ryvius.pekin.waw.pl> References: <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427165704.GC3831@neu.nirvana> <20070427180311.GB23643@ryvius.pekin.waw.pl> Message-ID: <20070427181311.GF3831@neu.nirvana> On Fri, Apr 27, 2007 at 08:03:11PM +0200, Dominik 'Rathann' Mierzejewski wrote: > In that case, you can have both 32bit and 64bit -libs installed (because > they don't conflict), but only one devel and one main package (because they > do conflict). Bingo! And you have the demand for a multilib development setup. And if the ppc/ppc64 versions differ in their usage of altivec which is passed over cflags and you really need two different fftw-config files? > So now you're talking about full multiarch support. We can talk about > that, but that's a MAJOR change and needs a separate evaluation. We've been talking about that from the very start of the bin64 thread, that's not a new course of discussion. > > > You install either 32bit or 64bit version and use that. Why switch > > > at all? > > > > So you never wanted to check how mplayer on i386/x86_64 behave? FWIW > > most users install mplayer.x86_64 and when they hit on something that > > doesn't work they are desperate about getting the i386 version. Same > > for firefox until now. > > yum remove mplayer && yum --enablerepo=\*i386 install mplayer. What's > the problem? On Fri, Apr 27, 2007 at 07:32:15PM +0200, Axel Thimm wrote: > # yum install mplayer.i386 > file /usr/bin/mplayer from mplayer.i386 conflicts with file /usr/bin/mplayer from installed mplayer.x86_64 > > # yum remove mplayer > mplayer is needed by ... > > # rpm -e --nodeps mplayer > # yum install mplayer.i386 > > # mplayer foo > > # yum install mplayer.x86_64 > file /usr/bin/mplayer from mplayer.x86_64 conflicts with file /usr/bin/mplayer from installed mplayer.i386 > > # rpm -e --nodeps mplayer.x86_64; yum install mplayer > Sorry, you are offline, please try later > > > The better solution: > > # yum install mplayer.i386 > # goi386 mplayer foo > > # mplayer foo > -- 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 dominik at greysector.net Fri Apr 27 18:14:35 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 20:14:35 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427173215.GD3831@neu.nirvana> References: <20070427024357.GA4732@humbolt.us.dell.com> <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> Message-ID: <20070427181435.GC23643@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 19:32, Axel Thimm wrote: > On Fri, Apr 27, 2007 at 05:35:03PM +0100, David Woodhouse wrote: > > On Fri, 2007-04-27 at 17:10 +0200, Axel Thimm wrote: [...] > > > mplayer on certain codecs come to mind, which would also benefit from > > > allowing both of them to install. mplayer foo fails? Then just try > > > /usr/bin/mplayer foo? It just works w/o packaging mplayer-32 on > > > x86_64? Great. > > > > This is solved with our existing setup, by just installing the 32-bit > > mplayer and not the 64-bit one. > > # yum install mplayer.i386 > file /usr/bin/mplayer from mplayer.i386 conflicts with file /usr/bin/mplayer from installed mplayer.x86_64 > > # yum remove mplayer > mplayer is needed by ... > > # rpm -e --nodeps mplayer > # yum install mplayer.i386 > > # mplayer foo > > # yum install mplayer.x86_64 > file /usr/bin/mplayer from mplayer.x86_64 conflicts with file /usr/bin/mplayer from installed mplayer.i386 > > # rpm -e --nodeps mplayer.x86_64; yum install mplayer > Sorry, you are offline, please try later > Currently it's no better. Assume we have 64bit mplayer installed. $ mplayer foo doesn't work, needs 32bit binary blob codecs # yum install mplayer.i386 $ mplayer foo still doesn't work! aargh, why? oh, wait, rpm just ignored the 32bit binary even though there's a file conflict! > The better solution: > > # yum install mplayer.i386 > # goi386 mplayer foo > s,goi386,chroot /emul, and we have Gentoo or Debian's pure64 solution. It's not a better solution, it's a different solution. Heck, it solves a different problem! > # mplayer foo > You don't need bin64 for that. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Fri Apr 27 18:22:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 20:22:56 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177695416.2755.624.camel@pmac.infradead.org> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> Message-ID: <20070427182256.GG3831@neu.nirvana> If anyone talks to David "the vulgar" Woodhouse, please pass on the following. On Fri, Apr 27, 2007 at 06:36:56PM +0100, David Woodhouse wrote: > On Fri, 2007-04-27 at 13:09 -0400, Jesse Keating wrote: > > On Friday 27 April 2007 12:35:03 David Woodhouse wrote: > > > > Hardly even Core. ppc for Core has 3076 32-bit packages, not 1286. > > > > > > Not on my planet. > > > > > > devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ > > > ls *.ppc.rpm | wc -l 1286 > > > > David, you're looking at the "Fedora" spin which is a subset of all the > > packages, some Core, some Extras. Axel is obviously looking at the full > > tree. > > Ah, thanks. If I look at my rawhide mirror, that helps me get slightly > closer to his inflated numbers Even when pointed to his errors by several people and demonstrants carrying banners with large errors, he stil remains Mr. Right. > -- but still I only get to 1974 files matching *.ppc.rpm. There are > only 3004 files in total. > > Perhaps he has a slightly fresher mirror, Or perhaps Mr. Right has an old one? > _and_ we've added seventy-odd packages recently, _and_ he was > listing all files instead of only the 32-bit packages. He certainly knows how to add (but how about Mr. Right, who "forgets" sbin, devel and that there is Core and Extras?). Itneresting nitpicking anyway for someone who was off in his numbers by factors from 2 to 15. > He conveniently didn't show what he did to count them, of course. On Fri, Apr 27, 2007 at 07:32:15PM +0200, Axel Thimm wrote: > # cd /storage/public/mirror/download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/os/Fedora; ls *.ppc.rpm | wc -l > 3076 If that doesn't count as showing, I wonder what does. Does Mr. Right read the mail he replies to at all? > But it doesn't matter -- I've already accepted his estimate of 14%, > which is fairly much in line with my own estimate and dramatically less > than his original "almost all specfiles" nonsense. The nonsense (since Mr. Right continues to be offensive in language) is Mr. Right's mixing of statements to his liking. Original: "packages carrying bin parts are the majority" "14% are those packages that carry both bin and lib components" So Mr. Right manages to compare apple and oranges, which is nonsense. QED. Let me summarize: o sloppy to bogus stats and metric o misquoting o vulgar talking are Mr. Right's contribution for a long-term, not short-sighted solution for the multilib problem. -- 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 Fri Apr 27 18:29:39 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 27 Apr 2007 20:29:39 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427181435.GC23643@ryvius.pekin.waw.pl> References: <20070427025841.GA6104@nostromo.devel.redhat.com> <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> Message-ID: <20070427182939.GH3831@neu.nirvana> On Fri, Apr 27, 2007 at 08:14:35PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > # yum install mplayer.i386 > > file /usr/bin/mplayer from mplayer.i386 conflicts with file /usr/bin/mplayer from installed mplayer.x86_64 > > > > # yum remove mplayer > > mplayer is needed by ... > > > > # rpm -e --nodeps mplayer > > # yum install mplayer.i386 > > > > # mplayer foo > > > > # yum install mplayer.x86_64 > > file /usr/bin/mplayer from mplayer.x86_64 conflicts with file /usr/bin/mplayer from installed mplayer.i386 > > > > # rpm -e --nodeps mplayer.x86_64; yum install mplayer > > Sorry, you are offline, please try later > > > > Currently it's no better. But we're trying to improve things, and while now using mplayer.i386 is not defined at all in the "unwritten multilib specification for FC2-F7", if you do say that with the bin sub-sub-packaging method it does work you hit the above usability problem. > Assume we have 64bit mplayer installed. > $ mplayer foo > doesn't work, needs 32bit binary blob codecs > # yum install mplayer.i386 > $ mplayer foo > still doesn't work! aargh, why? oh, wait, rpm just ignored the 32bit binary > even though there's a file conflict! > Yes, the current and proposed bin sub-subpackaging solutions both make you throw the laptop out of the window, so let's go for a solution where the laptop stays on board, e.g. bin64. > > The better solution: > > > > # yum install mplayer.i386 > > # goi386 mplayer foo > > > > s,goi386,chroot /emul, > > and we have Gentoo or Debian's pure64 solution. It's not a better solution, > it's a different solution. Heck, it solves a different problem! How is it different? They want to run i386 on x86_64 and have a clean separation. > > > > You don't need bin64 for that. I agree, it was 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 dominik at greysector.net Fri Apr 27 18:36:53 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 20:36:53 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427180842.GE3831@neu.nirvana> References: <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> <20070427180842.GE3831@neu.nirvana> Message-ID: <20070427183653.GD23643@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 20:08, Axel Thimm wrote: > On Fri, Apr 27, 2007 at 07:57:11PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 27 April 2007 at 19:34, Ed Hill wrote: > > > There are no technical reasons why it can't be done so why try to > > > impose some artificial (and IMO self-defeating) barriers? > > > > Because that's what we've been doing for years? > > But honestly, that really isn't a reason for not fixing something? I'm all for fixing, but not by changing known behaviour all of a sudden instead of fixing what's broken. > > If you want to start talking about multiarching, we can do that, > > too, but the topic at hand is different. > > One way to solve all multilib problems is to scratch multilib I agree. I use pure arch anyway. > and use multiarch, e.g. avoid the arch-overwriting mechanism we currently > use, so I wouldn't say we're off-topic in considering multi-arch. Well not in near future anyway (read: F7). Perhaps for F8/F9. > > Yes, there's no technical reason for not installing both 32bit and 64bit > > version at the same time, but it means we'd need to go down the bin{32,64} > > path and that's a major change which I'm firmly against. > > OK, but why? Any suggestions need to be considered based on benefits > and drawbacks. If at the end there are more benefits that drawback one > chooses that, but w/o analysing it and blocking something from the > start you may miss important opportunities. I think multiarch is pointless (chroot solves that without rebuilding everything). Having said that, let's consider it. We have the following options: 1a) on x86_64: primary arch is 64bit and /bin /lib etc contain 64bit binaries. secondary arch is 32bit and /bin32 /lib32 etc contain 32bit binaries. 1b) on x86_64: primary arch is 64bit and /bin64 /lib64 etc contain 64bit binaries. secondary arch is 32bit and /bin /lib etc contain 32bit binaries. 2) on ppc64/sparc64: primary arch is 32bit and /bin /lib etc contain 32bit binaries secondary arch is 64bit and /bin64 /lib64 etc contain 64bit binaries. 2) is straightforward, requires putting bin64 after bin in $PATH. 1a is IMHO "natural", but requires different 32bit repo for x86_64. 1b requires putting bin64 first in $PATH. That probably leaves us with 1b and 2. So while I may not like it, I see no technical reason against this solution. Nevertheless I still don't like it! In an ideal world, we'd have just /bin and /lib (etc.) containing native binaries. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Fri Apr 27 18:42:03 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 27 Apr 2007 20:42:03 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427182939.GH3831@neu.nirvana> References: <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> Message-ID: <20070427184203.GE23643@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 20:29, Axel Thimm wrote: > On Fri, Apr 27, 2007 at 08:14:35PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > # yum install mplayer.i386 > > > file /usr/bin/mplayer from mplayer.i386 conflicts with file /usr/bin/mplayer from installed mplayer.x86_64 > > > > > > # yum remove mplayer > > > mplayer is needed by ... > > > > > > # rpm -e --nodeps mplayer > > > # yum install mplayer.i386 > > > > > > # mplayer foo > > > > > > # yum install mplayer.x86_64 > > > file /usr/bin/mplayer from mplayer.x86_64 conflicts with file /usr/bin/mplayer from installed mplayer.i386 > > > > > > # rpm -e --nodeps mplayer.x86_64; yum install mplayer > > > Sorry, you are offline, please try later > > > > > > > Currently it's no better. > > But we're trying to improve things, and while now using mplayer.i386 > is not defined at all in the "unwritten multilib specification for > FC2-F7", if you do say that with the bin sub-sub-packaging method it > does work you hit the above usability problem. It's not meant to solve the problem of running 32bit and 64bit _binaries_ simultaneously. It's meant to solve the problem of installing 32bit and 64bit _libs_ simultaneously. > > Assume we have 64bit mplayer installed. > > $ mplayer foo > > doesn't work, needs 32bit binary blob codecs > > # yum install mplayer.i386 > > $ mplayer foo > > still doesn't work! aargh, why? oh, wait, rpm just ignored the 32bit binary > > even though there's a file conflict! > > > > Yes, the current and proposed bin sub-subpackaging solutions both make > you throw the laptop out of the window, so let's go for a solution > where the laptop stays on board, e.g. bin64. You're trying to solve a different problem. > > > The better solution: > > > > > > # yum install mplayer.i386 > > > # goi386 mplayer foo > > > > > > > s,goi386,chroot /emul, > > > > and we have Gentoo or Debian's pure64 solution. It's not a better solution, > > it's a different solution. Heck, it solves a different problem! > > How is it different? They want to run i386 on x86_64 and have a clean > separation. But we never allowed that! Except for broken packages which keep binaries outside /bin directories. That's a major change of functionality, hence my saying that's a different problem. > > > > > > > You don't need bin64 for that. > > I agree, it was a joke. I wasn't referring to your joke. Sorry if I was unclear. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dwmw2 at infradead.org Fri Apr 27 19:07:48 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 27 Apr 2007 20:07:48 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427182256.GG3831@neu.nirvana> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> Message-ID: <1177700868.2755.655.camel@pmac.infradead.org> On Fri, 2007-04-27 at 20:22 +0200, Axel Thimm wrote: > If anyone talks to David "the vulgar" Woodhouse, please pass on the following. Do grow up if you want to be taken seriously, Axel. One comment about masturbation over pointless statistics really doesn't count as a reason to resort to the kindergarten "tell him I'm not talking to him" routine, amongst normal adults. > > He conveniently didn't show what he did to count them, of course. > > On Fri, Apr 27, 2007 at 07:32:15PM +0200, Axel Thimm wrote: > > # cd /storage/public/mirror/download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/os/Fedora; ls *.ppc.rpm | wc -l > > 3076 > > If that doesn't count as showing, I wonder what does. Does Mr. Right > read the mail he replies to at all? As the References: header makes clear, I didn't reply to that mail. I received it only after sending the other mail you're quoting. > > But it doesn't matter -- I've already accepted his estimate of 14%, > > which is fairly much in line with my own estimate and dramatically less > > than his original "almost all specfiles" nonsense. > > The nonsense (since Mr. Right continues to be offensive in language) > is Mr. Right's mixing of statements to his liking. > > Original: "packages carrying bin parts are the majority" > "14% are those packages that carry both bin and lib components" > > So Mr. Right manages to compare apple and oranges, which is nonsense. QED. You seem to have a short memory. You said, in <20070427074939.GB31607 at neu.nirvana>: -> o Rewrite almost all specfiles to sub-subpackage *-bin and manage the -> conflicting bin suppackages Christian said he was 'hardly convinced that represents "almost all specfiles"', and I did a very quick estimation of some numbers, coming up with a figure of about 10% or suggesting that we could push it up to 20% if we calculate differently. Then I accepted your 'correction' of 14%, and you still seem to want to go on about it. I probably should have listened to those who told me to ignore you as a kook, and not bothered to work out the numbers. As I already said, it doesn't actually matter anyway. But I was willing to give you a chance to prove them wrong and listen to what you had to say. I think I've probably heard enough now. > Let me summarize: > > o sloppy to bogus stats and metric The stats were very rough, yes -- I was only trying to back up Christian's assertion that it wasn't "almost all specfiles". But since they were so rough, I provided the working to go with them, so that they could be improved if anyone cared. You did seem to care, and you 'corrected' me. My original estimate was the lower end of the 10%-20% range. You corrected it to 14%, which I accepted readily. It really doesn't matter. > o misquoting No, I think you're getting confused again. Every misquote I've seen has been from your side. I really have no need to resort to such tactics -- especially when you harp on about the numbers I've already agreed with, and send mail like the one I'm replying to. > o vulgar talking Yep, because that's really relevant to a technical conversation. > are Mr. Right's contribution for a long-term, not short-sighted > solution for the multilib problem. I do appreciate the accolade, but there is no need for you to call me 'Mr. Right'. The technical side of the conversation stands up on its own. Thank you, and goodbye. -- dwmw2 From martin.sourada at seznam.cz Fri Apr 27 19:10:03 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 27 Apr 2007 21:10:03 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46320C6C.7090803@hhs.nl> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> Message-ID: <46324A8B.4010105@seznam.cz> Hans de Goede napsal(a): > Matthias Clasen wrote: >> On Fri, 2007-04-27 at 08:14 +0400, Peter Lemenkov wrote: >>>> On my system right now, /usr/share/locale takes up 373MB, dwarfing >>>> whatever Firefox uses. Splitting out Firefox's langpacks won't solve >>>> your problem. >>> Does that the reason not to splitting Firefox? I think it's only the >>> evidence that someone doesn't know something about macros in rpm >>> configs. ) >>> >>> Take a look at %_install_langs macro - we can control installing >>> langpacks using it but not in case of firefox. >> >> So, this is just a request to add proper %lang annotations to the >> firefox file lists ? >> > > Yes and no, Peter's original request really was for seperate (sub) > packages. But Peter's problem can be solved too (and probably better) by > adding proper > %lang annotations to the firefox file lists. This all AFAIK. > > Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > I'd like to add my 2$ as well to this issue.. so.. We have usual OSS applications that handle locales via *.po/*.mo files. These can (and must) be handled in spec file. I don't have any problems with this. But firefox is different. Far different. First, it ships langpacks separately from main programme, in *.xpi files. Second, Firefox's langpacks are extensions not proper locale AFAIK. So if yum and anaconda could be patched to install desired langpacks for applications like OOo and FF that could have it splitted into separate packages automatically then I think Firefox's langpacks should be in separated packages. If we don't have this functionality we should stick with langpacks inside the main package - but IMO that is not a good solution. Just because they are handled as extensions by upstream they should be handled as extensions in fedora as well. I don't see any technical or other reason which would block this. Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From caillon at redhat.com Fri Apr 27 19:35:06 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 27 Apr 2007 15:35:06 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46324A8B.4010105@seznam.cz> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> Message-ID: <4632506A.40601@redhat.com> Martin Sourada wrote: > Hans de Goede napsal(a): >> Matthias Clasen wrote: >>> On Fri, 2007-04-27 at 08:14 +0400, Peter Lemenkov wrote: >>>>> On my system right now, /usr/share/locale takes up 373MB, dwarfing >>>>> whatever Firefox uses. Splitting out Firefox's langpacks won't solve >>>>> your problem. >>>> Does that the reason not to splitting Firefox? I think it's only the >>>> evidence that someone doesn't know something about macros in rpm >>>> configs. ) >>>> >>>> Take a look at %_install_langs macro - we can control installing >>>> langpacks using it but not in case of firefox. >>> >>> So, this is just a request to add proper %lang annotations to the >>> firefox file lists ? >>> >> >> Yes and no, Peter's original request really was for seperate (sub) >> packages. But Peter's problem can be solved too (and probably better) by >> adding proper >> %lang annotations to the firefox file lists. This all AFAIK. >> >> Regards, >> >> Hans >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > > I'd like to add my 2$ as well to this issue.. so.. We have usual OSS > applications that handle locales via *.po/*.mo files. These can (and must) be > handled in spec file. I don't have any problems with this. But firefox is > different. Far different. First, it ships langpacks separately from main > programme, in *.xpi files. That's an implementation detail, really. This discussion should be format-independent. Should I replace the 12 MB of .zip (yes that's all .xpi are) files with 20MB+ of uncompressed .po files? Will that cause people to stop complaining? Second, Firefox's langpacks are extensions not proper > locale AFAIK. AFAIK, this is not a proper argument. Please explain. From blizzard at redhat.com Fri Apr 27 19:47:53 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 27 Apr 2007 15:47:53 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <46323B48.1060906@redhat.com> References: <200704261322.01077.jkeating@redhat.com> <1177677650.25112.9.camel@localhost.localdomain> <1177696878.32569.4.camel@localhost.localdomain> <200704271358.23727.jkeating@redhat.com> <46323B48.1060906@redhat.com> Message-ID: <1177703273.27777.0.camel@localhost.localdomain> On Fri, 2007-04-27 at 14:04 -0400, Christopher Aillon wrote: > Jesse Keating wrote: > > On Friday 27 April 2007 14:01:18 Paul W. Frields wrote: > >> Crap, the >1 link thing. /me crumples earlier post. > > > > IIRC >1 isn't a requirement. Just it has to have a _different_ link than the > > link used last time. > > But >1 is clearly more bettar. :P Moar l1nks!!!1!!oneone!!1 --Chris From martin.sourada at seznam.cz Fri Apr 27 20:12:42 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 27 Apr 2007 22:12:42 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4632506A.40601@redhat.com> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> Message-ID: <4632593A.50104@seznam.cz> Christopher Aillon napsal(a): > Martin Sourada wrote: >> >> I'd like to add my 2$ as well to this issue.. so.. We have usual OSS >> applications that handle locales via *.po/*.mo files. These can (and >> must) be >> handled in spec file. I don't have any problems with this. But firefox is >> different. Far different. First, it ships langpacks separately from main >> programme, in *.xpi files. > > That's an implementation detail, really. This discussion should be > format-independent. Should I replace the 12 MB of .zip (yes that's all > .xpi are) files with 20MB+ of uncompressed .po files? Will that cause > people to stop complaining? > Well, IMO it's not ONLY an implementation detail. Most of applications have locales in /usr/share/locale/*/LC_MESSAGES/app-name.mo. Why should firefox be different? Either it doesn't work this way, or you have other reason to do it other way. If you put the *.mo files in LC_MESSAGES you will handle locales IMO properly, firefox will boot faster because the locales won't be handled by it as extensions BUT will it work this way? To be fair I dunno. If you decide to keep it in the xpi file under /usr/lib/firefox-*/extensions/langpack* then you agree with firefox developers that it is an extension. And so it IMO should be in separate package - if there is a way how to make it work well. And since we have langpacks separated for OOo, I think the way is here. > Second, Firefox's langpacks are extensions not proper >> locale AFAIK. > > AFAIK, this is not a proper argument. Please explain. > Well, I overdo it a bit with use of word proper, yet, firefox handle it as an extension and that make the extension list grow and to check for compatibility whenever you upgrade to new version. I don't mind if I have tens of directories under /usr/share/locale, but quite dislike that I have tens of extension in clean firefox install. OK, you say it is in xpi, because it is too big without compression, then, why not split it from the main package? IMO it is reasonable to either have firefox locales among other locales (i.e. in /usr/share/locale), or have firefox langpacks in separate packages, possibly with dictionaries included, if firefox has not been patched yet to use the hunspell ones (splitted from OOo). > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Fri Apr 27 20:16:16 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 27 Apr 2007 16:16:16 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4632593A.50104@seznam.cz> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> Message-ID: <20070427201616.GA25329@jadzia.bu.edu> On Fri, Apr 27, 2007 at 10:12:42PM +0200, Martin Sourada wrote: > Well, I overdo it a bit with use of word proper, yet, firefox handle it as > an extension and that make the extension list grow and to check for > compatibility whenever you upgrade to new version. I don't mind if I have > tens of directories under /usr/share/locale, but quite dislike that I have > tens of extension in clean firefox install. OK, you say it is in xpi, Take a look at Firefox 2.0.x. The new Add-ons manager puts Extensions, Themes, and Languages all in different sections. Does that solve your problem? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From martin.sourada at seznam.cz Fri Apr 27 20:24:07 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Fri, 27 Apr 2007 22:24:07 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <20070427201616.GA25329@jadzia.bu.edu> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> <20070427201616.GA25329@jadzia.bu.edu> Message-ID: <46325BE7.8090102@seznam.cz> Matthew Miller napsal(a): > On Fri, Apr 27, 2007 at 10:12:42PM +0200, Martin Sourada wrote: >> Well, I overdo it a bit with use of word proper, yet, firefox handle it as >> an extension and that make the extension list grow and to check for >> compatibility whenever you upgrade to new version. I don't mind if I have >> tens of directories under /usr/share/locale, but quite dislike that I have >> tens of extension in clean firefox install. OK, you say it is in xpi, > > Take a look at Firefox 2.0.x. The new Add-ons manager puts Extensions, > Themes, and Languages all in different sections. Does that solve your > problem? > > Partly - the huge number of installed extensions in clean install isn't there, but still, AFAIK, internally they are still handled as extensions and that could possibly slow the firefox down (because that would mean you could have tens of extensions loading whenever firefox starts). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From caillon at redhat.com Fri Apr 27 20:52:34 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 27 Apr 2007 16:52:34 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4632593A.50104@seznam.cz> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> Message-ID: <46326292.8080606@redhat.com> Martin Sourada wrote: > Well, IMO it's not ONLY an implementation detail. Most of applications have > locales in /usr/share/locale/*/LC_MESSAGES/app-name.mo. Why should firefox be > different? Because the system doesn't work for it. The po system works great for GNOME applications where the translators are heavily using Linux and don't necessarily mind looking through source files to make changes. The sources for any individual application don't change as much as the sources for Firefox does. The .po file would be large and any change to the source coupled with a language change would make it extremely hard to track down precisely what needs an updated translation without tracking down source changelogs and even then it would not be easy. The majority of people writing Firefox translations run Windows and have no technology background whatsoever. The .po system just does not work for the project, so please don't try to force them to use it. > Either it doesn't work this way, or you have other reason to do it > other way. If you put the *.mo files in LC_MESSAGES you will handle locales IMO > properly, firefox will boot faster because the locales won't be handled by it as > extensions BUT will it work this way? I can do this another way but that is not the solution. They don't _have_ to be in extensions but it much easier to do so. The real solution is to fix firefox to not be so slow here. Stop bringing up browser bugs to the discussion. > then you agree with firefox developers I am a Firefox developer, so there is always at least one that I agree with. > Well, I overdo it a bit with use of word proper, yet, firefox handle it as an > extension and that make the extension list grow and to check for compatibility > whenever you upgrade to new version. And some things are mistranslated and the browser hangs when I use flash. These are just bugs. They are irrelevant to this discussion on packaging langpacks. Please stop pretending they are. > I don't mind if I have tens of directories > under /usr/share/locale, but quite dislike that I have tens of extension in > clean firefox install. Good to know. > OK, you say it is in xpi, because it is too big without > compression, No, I said it is in .xpi because it is the format that works best for the project. The fact that it is compressed is a bonus. I personally don't care how big they are. I'm not the person who started the thread because of things being "too big." > then, why not split it from the main package? Many reasons have been provided by me, and others. > IMO it is reasonable > to either have firefox locales among other locales (i.e. in /usr/share/locale), > or have firefox langpacks in separate packages So you are essentially saying that it is reasonable to install translations in the main package and in separate packages. I already picked the former. From caillon at redhat.com Fri Apr 27 20:53:40 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 27 Apr 2007 16:53:40 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46325BE7.8090102@seznam.cz> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> <20070427201616.GA25329@jadzia.bu.edu> <46325BE7.8090102@seznam.cz> Message-ID: <463262D4.2090501@redhat.com> Martin Sourada wrote: > Partly - the huge number of installed extensions in clean install isn't there, > but still, AFAIK, internally they are still handled as extensions and that could > possibly slow the firefox down (because that would mean you could have tens of > extensions loading whenever firefox starts). Once more, this is not a problem with translations but with the way firefox loads .xpi files. From ed at eh3.com Fri Apr 27 21:59:16 2007 From: ed at eh3.com (Ed Hill) Date: Fri, 27 Apr 2007 17:59:16 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427184203.GE23643@ryvius.pekin.waw.pl> References: <20070427074939.GB31607@neu.nirvana> <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> Message-ID: <20070427175916.78d71fe2@daggett> On Fri, 27 Apr 2007 20:42:03 "Dominik 'Rathann' Mierzejewski" wrote: > On Friday, 27 April 2007 at 20:29, Axel Thimm wrote: > > On Fri, Apr 27, 2007 at 08:14:35PM +0200, Dominik 'Rathann' > > Mierzejewski wrote: > > > > Assume we have 64bit mplayer installed. > > > $ mplayer foo > > > doesn't work, needs 32bit binary blob codecs > > > # yum install mplayer.i386 > > > $ mplayer foo > > > still doesn't work! aargh, why? oh, wait, rpm just ignored the > > > 32bit binary even though there's a file conflict! > > > > > > > Yes, the current and proposed bin sub-subpackaging solutions both > > make you throw the laptop out of the window, so let's go for a > > solution where the laptop stays on board, e.g. bin64. > > You're trying to solve a different problem. > Lets make this absolutely clear: a lot of people (myself included) want to see the above problem solved. I WANT my users (each and every one of them on multi-user systems in fact) to be able to switch at will between 32-bit and 64-bit versions of various applications. The following: - users performing installs - chroots that require special (e.g., root) permissions - virtual machines (that again probably require some special permissions and/or a lot of hassle) are all non-starters. And, again from my perspective, manipulation of ${PATH} for each user is just fine. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Sat Apr 28 03:47:27 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 27 Apr 2007 19:47:27 -0800 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <463262D4.2090501@redhat.com> References: <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> <20070427201616.GA25329@jadzia.bu.edu> <46325BE7.8090102@seznam.cz> <463262D4.2090501@redhat.com> Message-ID: <604aa7910704272047ud19a0f6ta70f69ec43be5e62@mail.gmail.com> On 4/27/07, Christopher Aillon wrote: > Once more, this is not a problem with translations but with the way > firefox loads .xpi files. Putting aside the issue of on-disk space for a moment.... and just focusing on the "potential" issue raised concerning runtime impact of parsing all these languages addons. In your estimation, would it be worthwhile to enhance firefox with a way to simply disable all languages other than the current locale? It's not clear to me there is a measurable runtime difference between having them all disabled or enabled at startup. I've disabled all of them manually in the addon-ons interface but I'm not sure its really impacting the startup time at all. Does disabling them in the addon interface prevent the xpi files from being parsed? -jef From dominik at greysector.net Sat Apr 28 05:42:22 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 28 Apr 2007 07:42:22 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427175916.78d71fe2@daggett> References: <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070427175916.78d71fe2@daggett> Message-ID: <20070428054222.GA29880@ryvius.pekin.waw.pl> On Friday, 27 April 2007 at 23:59, Ed Hill wrote: > On Fri, 27 Apr 2007 20:42:03 "Dominik 'Rathann' Mierzejewski" wrote: > > On Friday, 27 April 2007 at 20:29, Axel Thimm wrote: > > > On Fri, Apr 27, 2007 at 08:14:35PM +0200, Dominik 'Rathann' > > > Mierzejewski wrote: > > > > > > Assume we have 64bit mplayer installed. > > > > $ mplayer foo > > > > doesn't work, needs 32bit binary blob codecs > > > > # yum install mplayer.i386 > > > > $ mplayer foo > > > > still doesn't work! aargh, why? oh, wait, rpm just ignored the > > > > 32bit binary even though there's a file conflict! > > > > > > > > > > Yes, the current and proposed bin sub-subpackaging solutions both > > > make you throw the laptop out of the window, so let's go for a > > > solution where the laptop stays on board, e.g. bin64. > > > > You're trying to solve a different problem. > > > > Lets make this absolutely clear: a lot of people (myself included) want > to see the above problem solved. I WANT my users (each and every one > of them on multi-user systems in fact) to be able to switch at will > between 32-bit and 64-bit versions of various applications. And I want a pure64 system with binaries in /bin so that I don't have to rewrite tons of my scripts. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From martin.sourada at seznam.cz Sat Apr 28 08:31:45 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sat, 28 Apr 2007 10:31:45 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46326292.8080606@redhat.com> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> <46326292.8080606@redhat.com> Message-ID: <46330671.4020506@seznam.cz> Christopher Aillon napsal(a): > Martin Sourada wrote: >> Well, IMO it's not ONLY an implementation detail. Most of applications >> have >> locales in /usr/share/locale/*/LC_MESSAGES/app-name.mo. Why should >> firefox be >> different? > > Because the system doesn't work for it. The po system works great for > GNOME applications where the translators are heavily using Linux and > don't necessarily mind looking through source files to make changes. The > sources for any individual application don't change as much as the > sources for Firefox does. The .po file would be large and any change to > the source coupled with a language change would make it extremely hard > to track down precisely what needs an updated translation without > tracking down source changelogs and even then it would not be easy. The > majority of people writing Firefox translations run Windows and have no > technology background whatsoever. The .po system just does not work for > the project, so please don't try to force them to use it. > I do not try to force them to use it. I write it in next sentence: >> Either it doesn't work this way, or you have other reason to do it >> other way. >> If you put the *.mo files in LC_MESSAGES you will handle >> locales IMO >> properly, firefox will boot faster because the locales won't be >> handled by it as >> extensions BUT will it work this way? > > I can do this another way but that is not the solution. They don't > _have_ to be in extensions but it much easier to do so. The real > solution is to fix firefox to not be so slow here. Stop bringing up > browser bugs to the discussion. > OK, so should be bugzilla filled against it, or it has been done? >> then you agree with firefox developers > > I am a Firefox developer, so there is always at least one that I agree > with. > I'm sorry, I didn't know that, yet though I didn't wrote it, I was thinking about most of firerox developers. >> Well, I overdo it a bit with use of word proper, yet, firefox handle >> it as an >> extension and that make the extension list grow and to check for >> compatibility >> whenever you upgrade to new version. > > And some things are mistranslated and the browser hangs when I use > flash. These are just bugs. They are irrelevant to this discussion on > packaging langpacks. Please stop pretending they are. > Then what do you think is relevant? I don't see there other reasons than these. >> I don't mind if I have tens of directories >> under /usr/share/locale, but quite dislike that I have tens of >> extension in >> clean firefox install. > > Good to know. > >> OK, you say it is in xpi, because it is too big without >> compression, > > No, I said it is in .xpi because it is the format that works best for > the project. The fact that it is compressed is a bonus. I personally > don't care how big they are. I'm not the person who started the thread > because of things being "too big." > Ok, misunderstood you at first. Sorry for that. >> then, why not split it from the main package? > > Many reasons have been provided by me, and others. > >> IMO it is reasonable >> to either have firefox locales among other locales (i.e. in >> /usr/share/locale), >> or have firefox langpacks in separate packages > > So you are essentially saying that it is reasonable to install > translations in the main package and in separate packages. I already > picked the former. > Well, yes, but not blindly. It's OK when translations are inside the package, but as I looked into some of the *.xpi, I see these are not only translation for the first and they are handled as extensions for the second. In this (and other similar cases like OOo) I think it is better to have it separated from the main package. But that's only my opinion. If majority of people are against it, I am OK with the current state. > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Sat Apr 28 11:17:26 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 28 Apr 2007 13:17:26 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427183653.GD23643@ryvius.pekin.waw.pl> References: <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> <20070427180842.GE3831@neu.nirvana> <20070427183653.GD23643@ryvius.pekin.waw.pl> Message-ID: <20070428111726.GA2187@neu.nirvana> On Fri, Apr 27, 2007 at 08:36:53PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 27 April 2007 at 20:08, Axel Thimm wrote: > > On Fri, Apr 27, 2007 at 07:57:11PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > On Friday, 27 April 2007 at 19:34, Ed Hill wrote: > > > > There are no technical reasons why it can't be done so why try to > > > > impose some artificial (and IMO self-defeating) barriers? > > > > > > Because that's what we've been doing for years? > > > > But honestly, that really isn't a reason for not fixing something? > > I'm all for fixing, but not by changing known behaviour all of a sudden > instead of fixing what's broken. It's not all of a sudden, it is something suggested for being reviewed for F8. > > > If you want to start talking about multiarching, we can do that, > > > too, but the topic at hand is different. > > > > One way to solve all multilib problems is to scratch multilib > > I agree. I use pure arch anyway. > > > and use multiarch, e.g. avoid the arch-overwriting mechanism we currently > > use, so I wouldn't say we're off-topic in considering multi-arch. > > Well not in near future anyway (read: F7). Perhaps for F8/F9. Check the subject line, it was never ever intended for F7. :) > > > Yes, there's no technical reason for not installing both 32bit and 64bit > > > version at the same time, but it means we'd need to go down the bin{32,64} > > > path and that's a major change which I'm firmly against. > > > > OK, but why? Any suggestions need to be considered based on benefits > > and drawbacks. If at the end there are more benefits that drawback one > > chooses that, but w/o analysing it and blocking something from the > > start you may miss important opportunities. > > I think multiarch is pointless (chroot solves that without rebuilding > everything). Having said that, let's consider it. > > We have the following options: > > 1a) > on x86_64: > primary arch is 64bit and /bin /lib etc contain 64bit binaries. > secondary arch is 32bit and /bin32 /lib32 etc contain 32bit binaries. > > 1b) > on x86_64: > primary arch is 64bit and /bin64 /lib64 etc contain 64bit binaries. > secondary arch is 32bit and /bin /lib etc contain 32bit binaries. > > 2) > on ppc64/sparc64: > primary arch is 32bit and /bin /lib etc contain 32bit binaries > secondary arch is 64bit and /bin64 /lib64 etc contain 64bit binaries. > > 2) is straightforward, requires putting bin64 after bin in $PATH. 1a is > IMHO "natural", but requires different 32bit repo for x86_64. 1b requires > putting bin64 first in $PATH. That probably leaves us with 1b and 2. > > So while I may not like it, I see no technical reason against this > solution. Nevertheless I still don't like it! > > In an ideal world, we'd have just /bin and /lib (etc.) containing > native binaries. There could also be 3) No one gets /bin, /lib directly, everything gets bult into bin32/bin64 etc. and bin and lib are set as follows (symlinks) i386: bin -> bin32, lib -> lib32 x86_64: bin -> bin64, lib -> lib64 ppc: bin -> bin32, lib -> lib32 ... That would give you proper symmetry, reusable packages from one arch onto another (e.g. not packaging extra i386 packages for x86_64), and bin/lib would always point to the native components. I think there are lots of variants, even using different folder names. The main aspect that separates this from multilib is that it has different folders for binaries of the different archs. And FWIW if that other folder is in a chroot, that would be fine with me as well (maybe not called multiarch anymore, but names are just sound and smoke) - the important thing is no more filecolor induced file overwrites or remove/install punchholes, and also not replacing this by file-conflicting bins that need to be redownloaded each time for switching. -- 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 28 11:22:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 28 Apr 2007 13:22:40 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070427184203.GE23643@ryvius.pekin.waw.pl> References: <20070427103207.6ea159fd@ludwig-alpha.unil.ch> <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> Message-ID: <20070428112240.GB2187@neu.nirvana> On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote: > You're trying to solve a different problem. The main issue is that while FC1.92 started by allowing selected libs form i386 to coexist to assist in installing i386 packages for not yet available x86_64 counterparts, it has evolved to more and more libs, even for stuff that none will really be interested to install the i386 part of, and even for developing i386 on x86_64. So the problem domain slovly changes and multilib is not adequate to serve the needs. We either need to admit that and reduce the specs to what multilib can do on paper and also fix the issues in implementation, or find a better solution that serves the changed demand. That's what this is all about, and given the bad history of multilib support in rpm, a solution that does not involve any fiddling with rpm, yum, anaconda, smart, apt, ... is preferred. > > > and we have Gentoo or Debian's pure64 solution. It's not a better solution, > > > it's a different solution. Heck, it solves a different problem! > > > > How is it different? They want to run i386 on x86_64 and have a clean > > separation. > > But we never allowed that! Except for broken packages which keep binaries > outside /bin directories. That's a major change of functionality, hence > my saying that's a different problem. OK, I understand. Still that's probably what we want at the end. -- 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 dominik at greysector.net Sat Apr 28 12:08:07 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 28 Apr 2007 14:08:07 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070428111726.GA2187@neu.nirvana> References: <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> <20070427180842.GE3831@neu.nirvana> <20070427183653.GD23643@ryvius.pekin.waw.pl> <20070428111726.GA2187@neu.nirvana> Message-ID: <20070428120807.GA32066@ryvius.pekin.waw.pl> On Saturday, 28 April 2007 at 13:17, Axel Thimm wrote: > On Fri, Apr 27, 2007 at 08:36:53PM +0200, Dominik 'Rathann' Mierzejewski wrote: [...] > > > > Well not in near future anyway (read: F7). Perhaps for F8/F9. > > Check the subject line, it was never ever intended for F7. :) Right. [...] > There could also be > > 3) No one gets /bin, /lib directly, everything gets bult into > bin32/bin64 etc. and bin and lib are set as follows (symlinks) > > i386: bin -> bin32, lib -> lib32 > x86_64: bin -> bin64, lib -> lib64 > ppc: bin -> bin32, lib -> lib32 > ... > > That would give you proper symmetry, reusable packages from one > arch onto another (e.g. not packaging extra i386 packages for > x86_64), and bin/lib would always point to the native components. > > I think there are lots of variants, even using different folder > names. The main aspect that separates this from multilib is that it > has different folders for binaries of the different archs. > > And FWIW if that other folder is in a chroot, that would be fine with > me as well (maybe not called multiarch anymore, but names are just > sound and smoke) - the important thing is no more filecolor induced > file overwrites or remove/install punchholes, and also not replacing > this by file-conflicting bins that need to be redownloaded each time > for switching. Hm, now that I think about it, can't it be achieved with rpm -ivh --relocate /bin=/bin32 and so on *without* rebuilding packages? Well, modulo hardcoded strings. I still don't like the idea of parallel installation of 32bit/64bit binaries. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bugs.michael at gmx.net Sat Apr 28 12:22:26 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 28 Apr 2007 14:22:26 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070428120807.GA32066@ryvius.pekin.waw.pl> References: <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> <20070427180842.GE3831@neu.nirvana> <20070427183653.GD23643@ryvius.pekin.waw.pl> <20070428111726.GA2187@neu.nirvana> <20070428120807.GA32066@ryvius.pekin.waw.pl> Message-ID: <20070428142226.54fb2b7c.bugs.michael@gmx.net> On Sat, 28 Apr 2007 14:08:07 +0200, Dominik 'Rathann' Mierzejewski wrote: > Hm, now that I think about it, can't it be achieved with rpm -ivh > --relocate /bin=/bin32 and so on *without* rebuilding packages? Well, > modulo hardcoded strings. No, since %_prefix is not /bin, and you can only relocate a single root prefix. From ed at eh3.com Sat Apr 28 12:29:51 2007 From: ed at eh3.com (Ed Hill) Date: Sat, 28 Apr 2007 08:29:51 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070428054222.GA29880@ryvius.pekin.waw.pl> References: <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070427175916.78d71fe2@daggett> <20070428054222.GA29880@ryvius.pekin.waw.pl> Message-ID: <20070428082951.6f91d94b@daggett> On Sat, 28 Apr 2007 07:42:22 "Dominik 'Rathann' Mierzejewski" wrote: > On Friday, 27 April 2007 at 23:59, Ed Hill wrote: > > On Fri, 27 Apr 2007 20:42:03 "Dominik 'Rathann' Mierzejewski" wrote: > > > On Friday, 27 April 2007 at 20:29, Axel Thimm wrote: > > > > On Fri, Apr 27, 2007 at 08:14:35PM +0200, Dominik 'Rathann' > > > > Mierzejewski wrote: > > > > > > > > Assume we have 64bit mplayer installed. > > > > > $ mplayer foo > > > > > doesn't work, needs 32bit binary blob codecs > > > > > # yum install mplayer.i386 > > > > > $ mplayer foo > > > > > still doesn't work! aargh, why? oh, wait, rpm just ignored the > > > > > 32bit binary even though there's a file conflict! > > > > > > > > > > > > > Yes, the current and proposed bin sub-subpackaging solutions > > > > both make you throw the laptop out of the window, so let's go > > > > for a solution where the laptop stays on board, e.g. bin64. > > > > > > You're trying to solve a different problem. > > > > Lets make this absolutely clear: a lot of people (myself included) > > want to see the above problem solved. I WANT my users (each and > > every one of them on multi-user systems in fact) to be able to > > switch at will between 32-bit and 64-bit versions of various > > applications. > > And I want a pure64 system with binaries in /bin so that I don't have > to rewrite tons of my scripts. I don't think our desires are mutually exclusive. I think there are technical solutions (perhaps involving soft links?) that will satisfy both of us. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Apr 28 13:15:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 28 Apr 2007 15:15:21 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177700868.2755.655.camel@pmac.infradead.org> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> Message-ID: <20070428131521.GA4926@neu.nirvana> On Fri, Apr 27, 2007 at 08:07:48PM +0100, David Woodhouse wrote: > On Fri, 2007-04-27 at 20:22 +0200, Axel Thimm wrote: > > If anyone talks to David "the vulgar" Woodhouse, please pass on the following. > > Do grow up if you want to be taken seriously, Axel. One comment about > masturbation over pointless statistics really doesn't count as a reason > to resort to the kindergarten "tell him I'm not talking to him" routine, > amongst normal adults. Ok, so repeatedly using vulgar talk, insults and further offencive talk counts as adolescent behaviour for you? Maybe it does in some of your social peer groups, but vulgarism is far beyond any netiquete and unwritten "code of conduct" of the Fedora Project. > > > He conveniently didn't show what he did to count them, of course. > > > > On Fri, Apr 27, 2007 at 07:32:15PM +0200, Axel Thimm wrote: > > > # cd /storage/public/mirror/download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/os/Fedora; ls *.ppc.rpm | wc -l > > > 3076 > > > > If that doesn't count as showing, I wonder what does. Does Mr. Right > > read the mail he replies to at all? > > As the References: header makes clear, I didn't reply to that mail. > I received it only after sending the other mail you're quoting. And as the contents of your mail that quote both Jesse's and mine numbers that we "seventy-odd" apart show you had read that mail. So the above is more than not reading, it shows that you are lying now. If you resort to lies then please try to pass them in a less obvious way. > > > But it doesn't matter -- I've already accepted his estimate of 14%, > > > which is fairly much in line with my own estimate and dramatically less > > > than his original "almost all specfiles" nonsense. > > > > The nonsense (since Mr. Right continues to be offensive in language) > > is Mr. Right's mixing of statements to his liking. > > > > Original: "packages carrying bin parts are the majority" > > "14% are those packages that carry both bin and lib components" > > > > So Mr. Right manages to compare apple and oranges, which is nonsense. QED. > > You seem to have a short memory. > You said, in <20070427074939.GB31607 at neu.nirvana>: > > -> o Rewrite almost all specfiles to sub-subpackage *-bin and manage the > -> conflicting bin suppackages Where does this reference "packages that contain bin and libs"? Why do you continue to do apples vs oranges? Why don't you *read* before replying? > Christian said he was 'hardly convinced that represents "almost all > specfiles"', and I did a very quick estimation of some numbers, > coming up with a figure of about 10% or suggesting that we could > push it up to 20% if we calculate differently. Then I accepted your > 'correction' of 14%, and you still seem to want to go on about it. The 14% was a correction of your "we only need to split bins of libs" revised model, not the real fact that you need to keep bins everywhere in their own sub-subpackage. That's why it's a sub-subpackage. Please try reading before replying. So let's really count the packages that are affected. This involves all package that have bins bundled together with something else, not only libs, but config files, %lang and %docs. Out of 4468 specfiles this affects 2616 which amounts to 59%. I'll admit I would expect more ("almost all"), but whatever quanity anyone associates with "almost all", 59% is nearer to that, than to "10%". FWIW, even if I had said 100%, I would be a factor of 1.7 off, while you are a factor of 5.9 off. > I probably should have listened to those who told me to ignore you as a > kook, Thanks for continuing to teach me adolescent behaviour. I was warned that you are easy on offending other people, but I wasn't aware that you resolt to vulgarism. > and not bothered to work out the numbers. You didn't, you provided sloppy to bogus numbers all along with a hit bogosity of a factor of 15! And when presented with the real numbers you tell people that they masturbated. A very adolescent and professional behaviour. > As I already said, it doesn't actually matter anyway. But I was > willing to give you a chance to prove them wrong and listen to what > you had to say. I did prove you wrong. Does that account to an apology for telling me that I masturbate? > I think I've probably heard enough now. > > > Let me summarize: > > > > o sloppy to bogus stats and metric > > The stats were very rough, yes -- I was only trying to back up > Christian's assertion that it wasn't "almost all specfiles". But since > they were so rough, I provided the working to go with them, so that they > could be improved if anyone cared. You did seem to care, and you > 'corrected' me. My original estimate was the lower end of the 10%-20% > range. You corrected it to 14%, which I accepted readily. It really > doesn't matter. Don't twist the numbers. I corrected some numbers that you produced, but the set of specfiles to fix (59%) are still closer to "almost all", than to "10% with and overestimated 20% upper bound". > > o misquoting > > No, I think you're getting confused again. Every misquote I've seen has > been from your side. I really have no need to resort to such tactics -- But you did, in this very last mail again. I never refered with almost all to bins-with-libs packages as you like to present it, and even after correcting you as many times, you still present it that way. > especially when you harp on about the numbers I've already agreed with, > and send mail like the one I'm replying to. Which you reply to w/o reading or understanding. > > o vulgar talking > > Yep, because that's really relevant to a technical conversation. Well, I'm glad that you informed us about your style of technical conversation, but I'm surely not allone if I ask to to refrain from this immediately. And please add o lying to the list of your contribution in this thread. > > are Mr. Right's contribution for a long-term, not short-sighted > > solution for the multilib problem. > > I do appreciate the accolade, but there is no need for you to call me > 'Mr. Right'. Do you prefer Mr. Vulgar? > The technical side of the conversation stands up on its own. Indeed. Not only are the amount of packages to adjust to your proposed model the majority indeed (59% specfile wise), but your model implies file-level conflicts on all these 59% of packages that rpm/yum/anaconda/smart/apt will choke on, does not allow coinstalls and requires a switch from one arch to another to redownload the packages. > Thank you, and goodbye. I'm still seeing you on these lists. I guess if you stop using vulgar talk you could stay. -- 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 caillon at redhat.com Sat Apr 28 15:22:21 2007 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 28 Apr 2007 11:22:21 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <604aa7910704272047ud19a0f6ta70f69ec43be5e62@mail.gmail.com> References: <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> <20070427201616.GA25329@jadzia.bu.edu> <46325BE7.8090102@seznam.cz> <463262D4.2090501@redhat.com> <604aa7910704272047ud19a0f6ta70f69ec43be5e62@mail.gmail.com> Message-ID: <463366AD.6050605@redhat.com> Jeff Spaleta wrote: > On 4/27/07, Christopher Aillon wrote: >> Once more, this is not a problem with translations but with the way >> firefox loads .xpi files. > > Putting aside the issue of on-disk space for a moment.... and just > focusing on the "potential" issue raised concerning runtime impact of > parsing all these languages addons. In your estimation, would it be > worthwhile to enhance firefox with a way to simply disable all > languages other than the current locale? I've been pondering doing some thing where the extensions are in a different directory and get copied to $appdir/extensions on startup on first use. It's not clear to me there is > a measurable runtime difference between having them all disabled or > enabled at startup. I've disabled all of them manually in the > addon-ons interface but I'm not sure its really impacting the startup > time at all. Does disabling them in the addon interface prevent the > xpi files from being parsed? No, it still needs to parse it, find it's uuid, and then figure out whether it's been disabled by comparing to the user's profile. From dwmw2 at infradead.org Sat Apr 28 15:31:22 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 28 Apr 2007 16:31:22 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070428131521.GA4926@neu.nirvana> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> Message-ID: <1177774282.2831.84.camel@pmac.infradead.org> On Sat, 2007-04-28 at 15:15 +0200, Axel Thimm wrote: > And as the contents of your mail that quote both Jesse's and mine > numbers that we "seventy-odd" apart show you had read that mail. So > the above is more than not reading, it shows that you are lying > now. If you resort to lies then please try to pass them in a less > obvious way. Axel, you're really making yourself look silly here. You'd already used the number 3074, but without explanation. Your _original_ use of that was even still present in the quotations where I said 'seventy-odd'. I didn't need to read your later mail to come up with that. Anyway, I think your mirror seems to be corrupted. Even today, there are only 1974 packages matching *.ppc.rpm at ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/os/Fedora/ Perhaps you've been rsyncing without the '--delete' option? Or had you copied the Extras packages in to make it look bigger? It's amusing to observe that the only figure for which you've actually provided your calculations doesn't seem to be genuine. You're doing a remarkably good job of applying the classic Ad Hominem to yourself here. I've certainly stopped taking you seriously. > > You said, in <20070427074939.GB31607 at neu.nirvana>: > > > > -> o Rewrite almost all specfiles to sub-subpackage *-bin and manage the > > -> conflicting bin suppackages > > Where does this reference "packages that contain bin and libs"? Why do > you continue to do apples vs oranges? Why don't you *read* before > replying? I compared your estimate of the number of specfiles we'd need to modify ("almost all"), with mine ("10-20%"). Why do you find that so confusing? > > Christian said he was 'hardly convinced that represents "almost all > > specfiles"', and I did a very quick estimation of some numbers, > > coming up with a figure of about 10% or suggesting that we could > > push it up to 20% if we calculate differently. Then I accepted your > > 'correction' of 14%, and you still seem to want to go on about it. > > The 14% was a correction of your "we only need to split bins of libs" > revised model, not the real fact that you need to keep bins everywhere > in their own sub-subpackage. That's why it's a sub-subpackage. Please > try reading before replying. > > So let's really count the packages that are affected. This involves > all package that have bins bundled together with something else, not > only libs, but config files, %lang and %docs. Out of 4468 specfiles > this affects 2616 which amounts to 59%. No, now you've started making stuff up again. The proposal is only that binary files should conflict. There's no need to make config files, translations and docs conflict too. You are, again, making stuff up to inflate the numbers -- which is weird, because the numbers really don't matter anyway. Even if we did have to touch every specfile in the distro -- like we did to change from 'Copyright' to 'License' -- if it's the right thing to do then it's the right thing to do. As I said, we've spent too long taking the easiest short-term 'solution' for multilib instead of really planning for the future. Being anal about the numbers just makes you look disturbed, especially when you go to such lengths to make them up. > I'll admit I would expect more ("almost all"), but whatever quanity > anyone associates with "almost all", 59% is nearer to that, than to > "10%". FWIW, even if I had said 100%, I would be a factor of 1.7 off, > while you are a factor of 5.9 off. > > > I probably should have listened to those who told me to ignore you as a > > kook, > > Thanks for continuing to teach me adolescent behaviour. I was warned > that you are easy on offending other people, but I wasn't aware that > you resolt to vulgarism. > > > and not bothered to work out the numbers. > > You didn't, you provided sloppy to bogus numbers all along with a hit > bogosity of a factor of 15! And when presented with the real numbers > you tell people that they masturbated. A very adolescent and > professional behaviour. Axel, I really can't be bothered to argue with your hyperbole. My original figures were close enough to your earlier estimate of 14%; you're having to make stuff up to vary them -- and it doesn't matter _anyway_. > > As I already said, it doesn't actually matter anyway. But I was > > willing to give you a chance to prove them wrong and listen to what > > you had to say. > > I did prove you wrong. Does that account to an apology for telling me > that I masturbate? The phrase 'masturbating over the precise numbers' or whatever it was that I said is a _metaphor_. Not a literal accusation of self-abuse. Seriously, grow up. I don't know why it touched a nerve -- and I don't _want_ to know. Just get over it. > > I think I've probably heard enough now. > > > > > Let me summarize: > > > > > > o sloppy to bogus stats and metric > > > > The stats were very rough, yes -- I was only trying to back up > > Christian's assertion that it wasn't "almost all specfiles". But since > > they were so rough, I provided the working to go with them, so that they > > could be improved if anyone cared. You did seem to care, and you > > 'corrected' me. My original estimate was the lower end of the 10%-20% > > range. You corrected it to 14%, which I accepted readily. It really > > doesn't matter. > > Don't twist the numbers. I corrected some numbers that you produced, > but the set of specfiles to fix (59%) are still closer to "almost > all", than to "10% with and overestimated 20% upper bound". > > > > o misquoting > > > > No, I think you're getting confused again. Every misquote I've seen has > > been from your side. I really have no need to resort to such tactics -- > > But you did, in this very last mail again. I never refered with almost > all to bins-with-libs packages as you like to present it, and even > after correcting you as many times, you still present it that way. I presented precisely what you said -- your claim that we would need to "rewrite almost almost all specfiles". In fact, we'd only need a relatively minor modification to maybe 14% of them. That figure only becomes 59% if we take your radical new suggestion of banning conflicts even in text files, which I suggest we should not do. I assume you weren't seriously proposing that, and it was just a way to inflate the numbers some more? > > especially when you harp on about the numbers I've already agreed with, > > and send mail like the one I'm replying to. > > Which you reply to w/o reading or understanding. > > > > o vulgar talking > > > > Yep, because that's really relevant to a technical conversation. > > Well, I'm glad that you informed us about your style of technical > conversation, but I'm surely not allone if I ask to to refrain from > this immediately. > > And please add > > o lying > > to the list of your contribution in this thread. Heh. I really don't know who you're trying to fool any more. You seem like an intelligent person -- you can't possibly have genuinely thought I was lying. Do you really think anyone's reading this thread and taking you seriously when you come out with stuff like that? The Ad Hominem doesn't work when you make yourself look more foolish than the person you're slandering. Concentrate on the technical discussion, please. We'll let those reading the archives judge whether they think I'm a liar or not. > > > are Mr. Right's contribution for a long-term, not short-sighted > > > solution for the multilib problem. > > > > I do appreciate the accolade, but there is no need for you to call me > > 'Mr. Right'. > > Do you prefer Mr. Vulgar? If you like. It doesn't detract from the technical conversation; it only makes you look foolish. Call me what you like, by all means. If it's all the same with you, I'll continue calling you 'Axel'. At least in public fora. > > The technical side of the conversation stands up on its own. > > Indeed. Not only are the amount of packages to adjust to your proposed > model the majority indeed (59% specfile wise), but your model implies > file-level conflicts on all these 59% of packages that > rpm/yum/anaconda/smart/apt will choke on, does not allow coinstalls > and requires a switch from one arch to another to redownload the > packages. Your 59% is misleading; you changed the rules to get to there from the 14% you earlier came up with. Not that it matters. I cannot speak for smart and apt, but rpm/yum/anaconda certainly don't have an issue with the existence of multiple packages which provide the same file -- we have that already, anyway. It all works fine, as long as yum and anaconda only try to install one at a time by default (which is already the right thing to do anyway; bug #235756). You've been told this before, and yet you still keep repeating the same nonsense. And yes, just as now: if you want to switch the binary from one arch to another, you need the original package of your desired arch available. Although it becomes a lot easier to switch than it is now, because when we get rid of the dirty hack in RPM to allow conflicts, bugs like #235524 go away. > > Thank you, and goodbye. > > I'm still seeing you on these lists. I guess if you stop using > vulgar talk you could stay. Thanks. That's very kind of you. -- dwmw2 From bpepple at fedoraproject.org Sun Apr 29 13:48:25 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 29 Apr 2007 09:48:25 -0400 Subject: Sub-Committee's Reporting to FESCo Message-ID: <1177854505.5779.8.camel@lincoln> At the last FESCo meeting, we discussed how FESCo wished the various sub-committees (EPEL, FPC) to report their weekly summaries. The initial proposal was to have the sub-committee send a summary to FESCo at least 24-hours before the FESCo weekly meeting. Then during the FESCo meeting, the chair would simply ask if there were "any objection to this week's report of at http://", and if necessary have a vote on any contentious issues. This works fine for the FPC since they meet on Tuesdays, but since EPEL meets on Wednesday they wouldn't be able to send out a summary in time for that week's FESCo meeting. So instead of having them wait till the following weeks meeting, do we want to have a guideline that on summaries that aren't sent to FESCo in time, FESCo members have 3 business days after the summary is sent to make any objections known? Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 nicolas.mailhot at laposte.net Sun Apr 29 13:57:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 29 Apr 2007 15:57:44 +0200 Subject: Sub-Committee's Reporting to FESCo In-Reply-To: <1177854505.5779.8.camel@lincoln> References: <1177854505.5779.8.camel@lincoln> Message-ID: <1177855064.10096.4.camel@rousalka.dyndns.org> Le dimanche 29 avril 2007 ? 09:48 -0400, Brian Pepple a ?crit : > So instead of having them wait till the > following weeks meeting, do we want to have a guideline that on > summaries that aren't sent to FESCo in time, FESCo members have 3 > business days after the summary is sent to make any objections known? If you write it this way you'll have fun defining what "business day" is in an i18n context -- 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 dominik at greysector.net Sun Apr 29 17:18:39 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 29 Apr 2007 19:18:39 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070428112240.GB2187@neu.nirvana> References: <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> Message-ID: <20070429171838.GA6503@ryvius.pekin.waw.pl> On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote: > On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > You're trying to solve a different problem. > > The main issue is that while FC1.92 started by allowing selected libs > form i386 to coexist to assist in installing i386 packages for not yet > available x86_64 counterparts, it has evolved to more and more libs, > even for stuff that none will really be interested to install the i386 > part of, and even for developing i386 on x86_64. > > So the problem domain slovly changes and multilib is not adequate to > serve the needs. We either need to admit that and reduce the specs to > what multilib can do on paper and also fix the issues in > implementation, or find a better solution that serves the changed > demand. > > That's what this is all about, and given the bad history of multilib > support in rpm, a solution that does not involve any fiddling with > rpm, yum, anaconda, smart, apt, ... is preferred. rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be installed. Current multilib allows you to run 32bit apps, for example googe-earth as well as develop/debug other 32bit software. That's good enough for me and I suspect for many people as well. Now if only yum wouldn't try to install both package.i386 and package.x86_64 when I try yum install package and if there were no problems with shared files between 32/64bit packages, all would be well. > > > > and we have Gentoo or Debian's pure64 solution. It's not a better solution, > > > > it's a different solution. Heck, it solves a different problem! > > > > > > How is it different? They want to run i386 on x86_64 and have a clean > > > separation. > > > > But we never allowed that! Except for broken packages which keep binaries > > outside /bin directories. That's a major change of functionality, hence > > my saying that's a different problem. > > OK, I understand. Still that's probably what we want at the end. You see, that's what I'm not convinced of. So far only two people expressed support for this: Ed and you. I think that's something the FESCo should vote on. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Christian.Iseli at licr.org Sun Apr 29 18:43:59 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Sun, 29 Apr 2007 20:43:59 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070428111726.GA2187@neu.nirvana> References: <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> <20070427180842.GE3831@neu.nirvana> <20070427183653.GD23643@ryvius.pekin.waw.pl> <20070428111726.GA2187@neu.nirvana> Message-ID: <20070429204359.6c0dc077@ludwig-alpha.unil.ch> On Sat, 28 Apr 2007 13:17:26 +0200, Axel Thimm wrote: > There could also be > > 3) No one gets /bin, /lib directly, everything gets bult into > bin32/bin64 etc. and bin and lib are set as follows (symlinks) > > i386: bin -> bin32, lib -> lib32 > x86_64: bin -> bin64, lib -> lib64 > ppc: bin -> bin32, lib -> lib32 > ... > > That would give you proper symmetry, reusable packages from one > arch onto another (e.g. not packaging extra i386 packages for > x86_64), and bin/lib would always point to the native components. Another type of thing that worries me with this schema: $ rpm -qf /bin/ls file /bin/ls is not owned by any package In short: you are throwing a whole lot of typical assumptions about a Unix/Linux system out the window... and my gut feeling is that they'll come back haunting us in various unpleasant ways for a long time. C From dwmw2 at infradead.org Sun Apr 29 18:54:49 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 29 Apr 2007 19:54:49 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070429204359.6c0dc077@ludwig-alpha.unil.ch> References: <20070426171648.GB7127@neu.nirvana> <1177614021.2755.430.camel@pmac.infradead.org> <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> <20070427180842.GE3831@neu.nirvana> <20070427183653.GD23643@ryvius.pekin.waw.pl> <20070428111726.GA2187@neu.nirvana> <20070429204359.6c0dc077@ludwig-alpha.unil.ch> Message-ID: <1177872889.3085.48.camel@pmac.infradead.org> On Sun, 2007-04-29 at 20:43 +0200, Christian Iseli wrote: > Another type of thing that worries me with this schema: > $ rpm -qf /bin/ls > file /bin/ls is not owned by any package That'll be fun for all the packages with dependencies on /bin/sh etc. :) -- dwmw2 From dwmw2 at infradead.org Sun Apr 29 19:46:11 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 29 Apr 2007 20:46:11 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070429171838.GA6503@ryvius.pekin.waw.pl> References: <1177671597.2755.504.camel@pmac.infradead.org> <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> Message-ID: <1177875971.3085.53.camel@pmac.infradead.org> On Sun, 2007-04-29 at 19:18 +0200, Dominik 'Rathann' Mierzejewski wrote: > rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be > installed. Current multilib allows you to run 32bit apps, for example > googe-earth as well as develop/debug other 32bit software. That's good > enough for me and I suspect for many people as well. Now if only yum > wouldn't try to install both package.i386 and package.x86_64 when I try > yum install package and if there were no problems with shared files > between 32/64bit packages, all would be well. That's bug #235756, btw. One of the bugs on the multilib tracker. Hopefully we can fix it immediately after F7 release. -- dwmw2 From jkeating at redhat.com Sun Apr 29 20:29:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 29 Apr 2007 13:29:54 -0700 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177872889.3085.48.camel@pmac.infradead.org> References: <20070426171648.GB7127@neu.nirvana> <20070429204359.6c0dc077@ludwig-alpha.unil.ch> <1177872889.3085.48.camel@pmac.infradead.org> Message-ID: <200704291329.58218.jkeating@redhat.com> On Sunday 29 April 2007 11:54:49 David Woodhouse wrote: > That'll be fun for all the packages with dependencies on /bin/sh etc. %ghost? Not that I think this is a good thing, but... -- 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 tgl at redhat.com Mon Apr 30 05:39:10 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 30 Apr 2007 01:39:10 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46326292.8080606@redhat.com> References: <46311585.20204@redhat.com> <1177682180.3495.7.camel@localhost.localdomain> <46320C6C.7090803@hhs.nl> <46324A8B.4010105@seznam.cz> <4632506A.40601@redhat.com> <4632593A.50104@seznam.cz> <46326292.8080606@redhat.com> Message-ID: <13760.1177911550@sss.pgh.pa.us> Christopher Aillon writes: > ... Because the system doesn't work for it. The po system works great for > GNOME applications where the translators are heavily using Linux and > don't necessarily mind looking through source files to make changes. > The sources for any individual application don't change as much as the > sources for Firefox does. The .po file would be large and any change to > the source coupled with a language change would make it extremely hard > to track down precisely what needs an updated translation without > tracking down source changelogs and even then it would not be easy. The > majority of people writing Firefox translations run Windows and have no > technology background whatsoever. The .po system just does not work for > the project, so please don't try to force them to use it. Hmm ... without wishing to defend any details of the .po system, doesn't the above argument boil down to "I have incompetent people doing my message translations"? There will *always* be cases where wording that the original author thought was clear is ambiguous for someone else. If a translator can't/won't look at the code-in-context to see what was meant --- or even realize that he doesn't understand, and must ask the coder for clarification --- he'll probably produce a bad translation. Translators don't need to be capable of writing $chosen-implementation- language, but if they are afraid to even read it, they are not going to be a net plus for your project. regards, tom lane From pertusus at free.fr Mon Apr 30 10:30:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 30 Apr 2007 12:30:44 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070429171838.GA6503@ryvius.pekin.waw.pl> References: <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> Message-ID: <20070430103044.GG2906@free.fr> On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > You see, that's what I'm not convinced of. So far only two people expressed > support for this: Ed and you. I think that's something the FESCo should vote > on. I am also agreeing with Axel and Ed that it is something desirable. I am also thinking that primary arch binaries should be in bin (maybe as links). -- Pat From Axel.Thimm at ATrpms.net Mon Apr 30 11:53:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Apr 2007 13:53:55 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070429171838.GA6503@ryvius.pekin.waw.pl> References: <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> Message-ID: <20070430115355.GC13906@neu.nirvana> On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote: > > On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > You're trying to solve a different problem. > > > > The main issue is that while FC1.92 started by allowing selected libs > > form i386 to coexist to assist in installing i386 packages for not yet > > available x86_64 counterparts, it has evolved to more and more libs, > > even for stuff that none will really be interested to install the i386 > > part of, and even for developing i386 on x86_64. > > > > So the problem domain slovly changes and multilib is not adequate to > > serve the needs. We either need to admit that and reduce the specs to > > what multilib can do on paper and also fix the issues in > > implementation, or find a better solution that serves the changed > > demand. > > > > That's what this is all about, and given the bad history of multilib > > support in rpm, a solution that does not involve any fiddling with > > rpm, yum, anaconda, smart, apt, ... is preferred. > > rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be > installed. Actually rpm did that before multilib was added, so in fact your request to "fix" rpm means to remove multilib support. With which I agree 100%, because that only inflicted pain. > Current multilib allows you to run 32bit apps, for example > googe-earth as well as develop/debug other 32bit software. That's > good enough for me and I suspect for many people as well. Now if > only yum wouldn't try to install both package.i386 and > package.x86_64 when I try yum install package and if there were no > problems with shared files between 32/64bit packages, all would be > well. Well, while some bugs could be fixed like the nuking of %doc and %lang (although it is agrued that the multilib design in rpm is so awkward that this requires major rewrite work in rpm which is why it isn't beeing done), others like the punchhole bug cannot w/o removing the multilib support in rpm. Which is why I summarized this as "multilib needs to die, multiarch rulez". > > > > > and we have Gentoo or Debian's pure64 solution. It's not a better solution, > > > > > it's a different solution. Heck, it solves a different problem! > > > > > > > > How is it different? They want to run i386 on x86_64 and have a clean > > > > separation. > > > > > > But we never allowed that! Except for broken packages which keep binaries > > > outside /bin directories. That's a major change of functionality, hence > > > my saying that's a different problem. > > > > OK, I understand. Still that's probably what we want at the end. > > You see, that's what I'm not convinced of. So far only two people expressed > support for this: Ed and you. I think that's something the FESCo should vote > on. Sure, fesco will have to vote on this, this is just a proposal to discuss and see what benefits/drwabacks it carries either evolving to something that will be used or maybe hitting a blocker and be dropped. -- 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 Mon Apr 30 12:01:29 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 30 Apr 2007 14:01:29 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070430115355.GC13906@neu.nirvana> References: <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> Message-ID: <1177934489.3587.119.camel@mccallum.corsepiu.local> On Mon, 2007-04-30 at 13:53 +0200, Axel Thimm wrote: > On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote: > > > On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > You're trying to solve a different problem. > > > > > > The main issue is that while FC1.92 started by allowing selected libs > > > form i386 to coexist to assist in installing i386 packages for not yet > > > available x86_64 counterparts, it has evolved to more and more libs, > > > even for stuff that none will really be interested to install the i386 > > > part of, and even for developing i386 on x86_64. > > > > > > So the problem domain slovly changes and multilib is not adequate to > > > serve the needs. We either need to admit that and reduce the specs to > > > what multilib can do on paper and also fix the issues in > > > implementation, or find a better solution that serves the changed > > > demand. > > > > > > That's what this is all about, and given the bad history of multilib > > > support in rpm, a solution that does not involve any fiddling with > > > rpm, yum, anaconda, smart, apt, ... is preferred. > > > > rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be > > installed. > > Actually rpm did that before multilib was added, so in fact your > request to "fix" rpm means to remove multilib support. rpm complaining about conflicting programs in {,/usr}/{,s}bin doesn't affect multilibs at all. Ralf From Axel.Thimm at ATrpms.net Mon Apr 30 12:01:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Apr 2007 14:01:23 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070429204359.6c0dc077@ludwig-alpha.unil.ch> References: <20070426193041.GB14127@neu.nirvana> <1177623564.2755.461.camel@pmac.infradead.org> <20070427002608.GC21691@neu.nirvana> <20070427164220.GF20840@ryvius.pekin.waw.pl> <20070427133436.6960960b@daggett> <20070427175711.GA23643@ryvius.pekin.waw.pl> <20070427180842.GE3831@neu.nirvana> <20070427183653.GD23643@ryvius.pekin.waw.pl> <20070428111726.GA2187@neu.nirvana> <20070429204359.6c0dc077@ludwig-alpha.unil.ch> Message-ID: <20070430120123.GD13906@neu.nirvana> On Sun, Apr 29, 2007 at 08:43:59PM +0200, Christian Iseli wrote: > On Sat, 28 Apr 2007 13:17:26 +0200, Axel Thimm wrote: > > There could also be > > > > 3) No one gets /bin, /lib directly, everything gets bult into > > bin32/bin64 etc. and bin and lib are set as follows (symlinks) > > > > i386: bin -> bin32, lib -> lib32 > > x86_64: bin -> bin64, lib -> lib64 > > ppc: bin -> bin32, lib -> lib32 > > ... > > > > That would give you proper symmetry, reusable packages from one > > arch onto another (e.g. not packaging extra i386 packages for > > x86_64), and bin/lib would always point to the native components. > > Another type of thing that worries me with this schema: > $ rpm -qf /bin/ls > file /bin/ls is not owned by any package > > In short: you are throwing a whole lot of typical assumptions > about a Unix/Linux system out the window... and my gut feeling is that > they'll come back haunting us in various unpleasant ways for a long > time. That's a problem in general that we need to be aware of. The moment any scheme starts not to prepare multilib/multiarch on the server side, but simply activate both repos on the client side you will have the issue that /bin/ls will be owned by two packages from different archs, and you need to hope that the depsolver will pick the right one. But this is a common issue with any scheme that will allow full unfiltered access to both repos. In the scheme 3) above one could automatically %ghost-own all (s)bin symlinks, which would solve the issue of /bin/ls existing in the rpm database, but not the general issue of parallel repo enablement. So, in a nutshell: There will be two classes of solutions, one that prepare the x86_64 repo with selected i386 packages, either white/blacklisted/heuristic based etc, or solutions that allow full access to the i386 repos. And the latter class of solution will have to deal with shared file dependencies. Both the bin64 and David's solution fall into the latter class. -- 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 Mon Apr 30 12:09:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Apr 2007 14:09:47 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177934489.3587.119.camel@mccallum.corsepiu.local> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <1177934489.3587.119.camel@mccallum.corsepiu.local> Message-ID: <20070430120947.GE13906@neu.nirvana> On Mon, Apr 30, 2007 at 02:01:29PM +0200, Ralf Corsepius wrote: > On Mon, 2007-04-30 at 13:53 +0200, Axel Thimm wrote: > > On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote: > > > > On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > > You're trying to solve a different problem. > > > > > > > > The main issue is that while FC1.92 started by allowing selected libs > > > > form i386 to coexist to assist in installing i386 packages for not yet > > > > available x86_64 counterparts, it has evolved to more and more libs, > > > > even for stuff that none will really be interested to install the i386 > > > > part of, and even for developing i386 on x86_64. > > > > > > > > So the problem domain slovly changes and multilib is not adequate to > > > > serve the needs. We either need to admit that and reduce the specs to > > > > what multilib can do on paper and also fix the issues in > > > > implementation, or find a better solution that serves the changed > > > > demand. > > > > > > > > That's what this is all about, and given the bad history of multilib > > > > support in rpm, a solution that does not involve any fiddling with > > > > rpm, yum, anaconda, smart, apt, ... is preferred. > > > > > > rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be > > > installed. > > > > Actually rpm did that before multilib was added, so in fact your > > request to "fix" rpm means to remove multilib support. > rpm complaining about conflicting programs in {,/usr}/{,s}bin doesn't > affect multilibs at all. Before multilib support in rpm, the current packages would fail like foo.i386 and foo.x86_64 conflicting files in /usr/bin/foo and not allow coinstallation. The multilib support made these conflicts go away for elfcolored files and made x86_64 silently win over i386 in the undone conflicts. -- 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 Mon Apr 30 12:38:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 30 Apr 2007 14:38:24 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070430120947.GE13906@neu.nirvana> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <1177934489.3587.119.camel@mccallum.corsepiu.local> <20070430120947.GE13906@neu.nirvana> Message-ID: <1177936704.4283.17.camel@mccallum.corsepiu.local> On Mon, 2007-04-30 at 14:09 +0200, Axel Thimm wrote: > On Mon, Apr 30, 2007 at 02:01:29PM +0200, Ralf Corsepius wrote: > > On Mon, 2007-04-30 at 13:53 +0200, Axel Thimm wrote: > > > On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote: > > > > > On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > > > You're trying to solve a different problem. > > > > > > > > > > The main issue is that while FC1.92 started by allowing selected libs > > > > > form i386 to coexist to assist in installing i386 packages for not yet > > > > > available x86_64 counterparts, it has evolved to more and more libs, > > > > > even for stuff that none will really be interested to install the i386 > > > > > part of, and even for developing i386 on x86_64. > > > > > > > > > > So the problem domain slovly changes and multilib is not adequate to > > > > > serve the needs. We either need to admit that and reduce the specs to > > > > > what multilib can do on paper and also fix the issues in > > > > > implementation, or find a better solution that serves the changed > > > > > demand. > > > > > > > > > > That's what this is all about, and given the bad history of multilib > > > > > support in rpm, a solution that does not involve any fiddling with > > > > > rpm, yum, anaconda, smart, apt, ... is preferred. > > > > > > > > rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be > > > > installed. > > > > > > Actually rpm did that before multilib was added, so in fact your > > > request to "fix" rpm means to remove multilib support. > > > rpm complaining about conflicting programs in {,/usr}/{,s}bin doesn't > > affect multilibs at all. > > Before multilib support in rpm, the current packages would fail like > > foo.i386 and foo.x86_64 conflicting files in /usr/bin/foo > > and not allow coinstallation. The multilib support made these > conflicts go away for elfcolored files and made x86_64 silently win > over i386 in the undone conflicts. Agreed, this likely is a bug. But a /usr/bin/foo being provided by foo.i386 and foo.x86_64 with and not conflicting otherwise (e.g. in libs underneath) should not be a problem. Ralf From maxime.carron at fedoraproject.org Mon Apr 30 13:12:21 2007 From: maxime.carron at fedoraproject.org (Maxime Carron) Date: Mon, 30 Apr 2007 15:12:21 +0200 Subject: No access on fedora extras cvs Message-ID: <1177938741.3189.40.camel@localhost.localdomain> Hi, i currently have a problem with the fedora extras cvs. It's my first package. The review request can be found here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229490 My first problem was that i can't update fedora-cvs status, ie can't set fedora-cvs to '?'. My sponsor and comaintainer to did it for me. My second problem is, i can't commit on the cvs. Here is what i've done : export CVSROOT=:ext:mxcarron at cvs.fedora.redhat.com:/cvs/extras export CVS_RSH=ssh cvs co pypar2 cd pypar2 ./common/cvs-import.sh ~/rpmbuild/SRPMS/pypar2-1.4-1.src.rpm and the log is : Checking out module: 'pypar2' Enter passphrase for key '/home/builder/.ssh/id_dsa': Unpacking source package: pypar2-1.4-1.src.rpm... L pypar2-1.4.tar.gz Enter passphrase for key '/home/builder/.ssh/id_dsa': A pypar2.spec Checking : pypar2-1.4.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... This file (d77ea7c0ff88209d994c5723c98d00a5 pypar2-1.4.tar.gz) is already uploaded Source upload succeeded. Don't forget to commit the new ./sources file Enter passphrase for key '/home/builder/.ssh/id_dsa': M sources M .cvsignore ======================================================================= Enter passphrase for key '/home/builder/.ssh/id_dsa': Index: import.log =================================================================== RCS file: /cvs/extras/rpms/pypar2/import.log,v retrieving revision 1.1 diff -u -r1.1 import.log --- import.log 28 Apr 2007 00:52:36 -0000 1.1 +++ import.log 29 Apr 2007 22:16:31 -0000 @@ -0,0 +1 @@ +pypar2-1_4-1:HEAD:pypar2-1.4-1.src.rpm:1177885112 Index: devel/.cvsignore =================================================================== RCS file: /cvs/extras/rpms/pypar2/devel/.cvsignore,v retrieving revision 1.1 diff -u -r1.1 .cvsignore --- devel/.cvsignore 28 Apr 2007 00:52:47 -0000 1.1 +++ devel/.cvsignore 29 Apr 2007 22:16:31 -0000 @@ -0,0 +1 @@ +pypar2-1.4.tar.gz cvs diff: devel/pypar2.spec is a new entry, no comparison available Index: devel/sources =================================================================== RCS file: /cvs/extras/rpms/pypar2/devel/sources,v retrieving revision 1.1 diff -u -r1.1 sources --- devel/sources 28 Apr 2007 00:52:47 -0000 1.1 +++ devel/sources 29 Apr 2007 22:16:31 -0000 @@ -0,0 +1 @@ +d77ea7c0ff88209d994c5723c98d00a5 pypar2-1.4.tar.gz ======================================================================= Please check the above cvs diff. If you want to make any changes before committing, please press Ctrl-C. Otherwise press Enter to proceed to commit. Enter passphrase for key '/home/builder/.ssh/id_dsa': cvs commit... Enter passphrase for key '/home/builder/.ssh/id_dsa': **** Access denied: mxcarron is not in ACL for rpms/pypar2 cvs commit: Pre-commit check failed **** Access denied: mxcarron is not in ACL for rpms/pypar2/devel cvs commit: Pre-commit check failed cvs [commit aborted]: correct above errors first! cvs commit: saving log message in /tmp/cvsTYkETc According to the account system, i'm in cvsextras and fedorabugs. I hope you can help me. Thanks, Maxime -- Maxime Carron Fedora Ambassador Fedora-fr Community Manager - http://www.fedora-fr.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pknirsch at redhat.com Mon Apr 30 13:24:12 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Mon, 30 Apr 2007 15:24:12 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070430115355.GC13906@neu.nirvana> References: <20070427121308.GB9711@neu.nirvana> <1177680019.2755.553.camel@pmac.infradead.org> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> Message-ID: <4635EDFC.9090704@redhat.com> Axel Thimm wrote: > On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote: >> On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote: >>> On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote: >>>> You're trying to solve a different problem. >>> The main issue is that while FC1.92 started by allowing selected libs >>> form i386 to coexist to assist in installing i386 packages for not yet >>> available x86_64 counterparts, it has evolved to more and more libs, >>> even for stuff that none will really be interested to install the i386 >>> part of, and even for developing i386 on x86_64. >>> >>> So the problem domain slovly changes and multilib is not adequate to >>> serve the needs. We either need to admit that and reduce the specs to >>> what multilib can do on paper and also fix the issues in >>> implementation, or find a better solution that serves the changed >>> demand. >>> >>> That's what this is all about, and given the bad history of multilib >>> support in rpm, a solution that does not involve any fiddling with >>> rpm, yum, anaconda, smart, apt, ... is preferred. >> rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be >> installed. > > Actually rpm did that before multilib was added, so in fact your > request to "fix" rpm means to remove multilib support. With which I > agree 100%, because that only inflicted pain. > >> Current multilib allows you to run 32bit apps, for example >> googe-earth as well as develop/debug other 32bit software. That's >> good enough for me and I suspect for many people as well. Now if >> only yum wouldn't try to install both package.i386 and >> package.x86_64 when I try yum install package and if there were no >> problems with shared files between 32/64bit packages, all would be >> well. > > Well, while some bugs could be fixed like the nuking of %doc and %lang > (although it is agrued that the multilib design in rpm is so awkward > that this requires major rewrite work in rpm which is why it isn't > beeing done), others like the punchhole bug cannot w/o removing the > multilib support in rpm. Which is why I summarized this as "multilib > needs to die, multiarch rulez". > One thing you have to be very careful about multiarch is that you don't fall for the easy solution. Just adding [loadsofprefixes]/bin64 will not fix world hunger, especially when you then suddenly in the years to come get a CPU that might support 32bit and 2 64bit archs. Then you're then screwed all over again, just like with the "No application will ever need more than 640kb." The solution debian and Gentoo iirc use which are basically buildroots is the only way i know how you can cleanly separate various archs on one system. Sadly you'll then loose the common and sharable files, but any other solution will need very carefull and detailed planing. (You could ofc ahackishly lways just run hardlink on / after each package installation ;) ). Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From buildsys at fedoraproject.org Mon Apr 30 18:49:08 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 30 Apr 2007 14:49:08 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-04-30 Message-ID: <20070430184908.D13E6152131@buildsys.fedoraproject.org> UNKNOWN OWNER (possibly Core package): m4 FC6-updates > FC7 (0:1.4.8-2 > 0:1.4.8-1) cbalint AT redhat.com: iverilog FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) mdehaan AT redhat.com: cobbler FE5 > FE6 (0:0.4.7-5.fc5 > 0:0.4.6-0.fc6) scott AT perturb.org: dstat FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) ---------------------------------------------------------------------- cobbler: mdehaan AT redhat.com FE5 > FE6 (0:0.4.7-5.fc5 > 0:0.4.6-0.fc6) dstat: scott AT perturb.org FE6 > FE7 (0:0.6.5-1.fc6 > 0:0.6.4-1.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) iverilog: cbalint AT redhat.com FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) m4: UNKNOWN OWNER (possibly Core package) FC6-updates > FC7 (0:1.4.8-2 > 0:1.4.8-1) From Axel.Thimm at ATrpms.net Mon Apr 30 19:46:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 30 Apr 2007 21:46:04 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <4635EDFC.9090704@redhat.com> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <4635EDFC.9090704@redhat.com> Message-ID: <20070430194603.GF13906@neu.nirvana> On Mon, Apr 30, 2007 at 03:24:12PM +0200, Phil Knirsch wrote: > Axel Thimm wrote: > >On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski > >wrote: > >>On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote: > >>>On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski > >>>wrote: > >>>>You're trying to solve a different problem. > >>>The main issue is that while FC1.92 started by allowing selected libs > >>>form i386 to coexist to assist in installing i386 packages for not yet > >>>available x86_64 counterparts, it has evolved to more and more libs, > >>>even for stuff that none will really be interested to install the i386 > >>>part of, and even for developing i386 on x86_64. > >>> > >>>So the problem domain slovly changes and multilib is not adequate to > >>>serve the needs. We either need to admit that and reduce the specs to > >>>what multilib can do on paper and also fix the issues in > >>>implementation, or find a better solution that serves the changed > >>>demand. > >>> > >>>That's what this is all about, and given the bad history of multilib > >>>support in rpm, a solution that does not involve any fiddling with > >>>rpm, yum, anaconda, smart, apt, ... is preferred. > >>rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be > >>installed. > > > >Actually rpm did that before multilib was added, so in fact your > >request to "fix" rpm means to remove multilib support. With which I > >agree 100%, because that only inflicted pain. > > > >>Current multilib allows you to run 32bit apps, for example > >>googe-earth as well as develop/debug other 32bit software. That's > >>good enough for me and I suspect for many people as well. Now if > >>only yum wouldn't try to install both package.i386 and > >>package.x86_64 when I try yum install package and if there were no > >>problems with shared files between 32/64bit packages, all would be > >>well. > > > >Well, while some bugs could be fixed like the nuking of %doc and %lang > >(although it is agrued that the multilib design in rpm is so awkward > >that this requires major rewrite work in rpm which is why it isn't > >beeing done), others like the punchhole bug cannot w/o removing the > >multilib support in rpm. Which is why I summarized this as "multilib > >needs to die, multiarch rulez". > > > > One thing you have to be very careful about multiarch is that you don't > fall for the easy solution. > > Just adding [loadsofprefixes]/bin64 will not fix world hunger, > especially when you then suddenly in the years to come get a CPU that > might support 32bit and 2 64bit archs. Then you're then screwed all over > again, just like with the "No application will ever need more than 640kb." You can refine this solution to not plain dump bin64 folders, but full triple-platform defining folders. In fact I think the original Debian multiarch suggestion went as far as to define it that way. The idea was not only to support 2,3,4 subarchs on a single system, but even sharing the same tree among their 11 something supported archs over NFS. Well, I wouldn't ever mount a "global NFS root". The point is that once you have undone any /usr/bin hardcoded paths in packages you can easily move them to any possible new layout. > The solution debian and Gentoo iirc use which are basically buildroots > is the only way i know how you can cleanly separate various archs on one > system. Sadly you'll then loose the common and sharable files, but any > other solution will need very carefull and detailed planing. Personally I prefer banning multilib in rpm for good and if that would be best done by using chroot solutions, I'm all for it. The multilib implementation within rpm magic just isn't scaling and produces more bugs on the way than we can fix. > (You could ofc ahackishly lways just run hardlink on / after each > package installation ;) ). > > Read ya, Phil > -- 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 Mon Apr 30 21:23:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Apr 2007 14:23:20 -0700 Subject: Buildsystem / CVS outage for the merger Message-ID: <200704301423.20451.jkeating@redhat.com> We're going to give the merger another go this Wed. This will require the buildsystem(s) to be offline as well as CVS during the merge process. We are targetting Wed 12:00pm EDT as the outage time (that's Noon). See http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge for details. -- 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 Mon Apr 30 21:31:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Apr 2007 14:31:03 -0700 Subject: Slight schedule change Message-ID: <200704301431.04337.jkeating@redhat.com> Instead of deep freezing for F7 Final this Thursday, the release team has decided to kick it out a week to next Thursday. This will give us a bit more time to shake things out with the merger happening this Wed. and allow for some builds for new BuildRequires (IE Core building against Extras) to happen and be tested. -- 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 ed at eh3.com Mon Apr 30 21:40:43 2007 From: ed at eh3.com (Ed Hill) Date: Mon, 30 Apr 2007 17:40:43 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070430194603.GF13906@neu.nirvana> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <4635EDFC.9090704@redhat.com> <20070430194603.GF13906@neu.nirvana> Message-ID: <20070430174043.696263de@daggett> On Mon, 30 Apr 2007 21:46:04 +0200 Axel Thimm wrote: > On Mon, Apr 30, 2007 at 03:24:12PM +0200, Phil Knirsch wrote: > > > The solution debian and Gentoo iirc use which are basically > > buildroots is the only way i know how you can cleanly separate > > various archs on one system. Sadly you'll then loose the common and > > sharable files, but any other solution will need very carefull and > > detailed planing. > > Personally I prefer banning multilib in rpm for good and if that would > be best done by using chroot solutions, I'm all for it. The multilib > implementation within rpm magic just isn't scaling and produces more > bugs on the way than we can fix. I'm not familiar with the chroots used in Debian or Gentoo. Can someone please say a few words about their usability? I'm just wondering about the following: - do chroots require special permissions or group memberships? - once you are in a chroot isn't it nearly impossible to access files outside it? Put differently, are there some interesting soft-linking or re-mounting gymnastics or other hacks going on here to get at, say, your ${HOME} or other random directories from a chroot-ed program? It just seems to me that chroots are probably a lot less usable than binaries placed in {,/usr}/{,s}bin64 or similar. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Apr 30 21:43:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Apr 2007 14:43:32 -0700 Subject: Slight schedule change In-Reply-To: References: <200704301431.04337.jkeating@redhat.com> Message-ID: <200704301443.32499.jkeating@redhat.com> On Monday 30 April 2007 14:40:04 dragoran dragoran wrote: > but this does not delay the release? As of yet, no. If we keep things somewhat sane during that extra week and don't allow a bunch of regressions it shouldn't have impact. -- 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 Mon Apr 30 22:49:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 00:49:11 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070430174043.696263de@daggett> References: <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <4635EDFC.9090704@redhat.com> <20070430194603.GF13906@neu.nirvana> <20070430174043.696263de@daggett> Message-ID: <20070430224911.GA30041@neu.nirvana> On Mon, Apr 30, 2007 at 05:40:43PM -0400, Ed Hill wrote: > On Mon, 30 Apr 2007 21:46:04 +0200 Axel Thimm wrote: > > On Mon, Apr 30, 2007 at 03:24:12PM +0200, Phil Knirsch wrote: > > > > > The solution debian and Gentoo iirc use which are basically > > > buildroots is the only way i know how you can cleanly separate > > > various archs on one system. Sadly you'll then loose the common and > > > sharable files, but any other solution will need very carefull and > > > detailed planing. > > > > Personally I prefer banning multilib in rpm for good and if that would > > be best done by using chroot solutions, I'm all for it. The multilib > > implementation within rpm magic just isn't scaling and produces more > > bugs on the way than we can fix. > > > I'm not familiar with the chroots used in Debian or Gentoo. Can someone > please say a few words about their usability? I'm just wondering about > the following: > > - do chroots require special permissions or group memberships? chroots require root priviledges to chroot into. These can be implemented by suid programs that become root, chroot and then drop priviledges again. > - once you are in a chroot isn't it nearly impossible to > access files outside it? Put differently, are there some > interesting soft-linking or re-mounting gymnastics or other > hacks going on here to get at, say, your ${HOME} or other > random directories from a chroot-ed program? The only way to access your $HOME is by mounting it into the chroot. Soft links can't help you. > It just seems to me that chroots are probably a lot less usable than > binaries placed in {,/usr}/{,s}bin64 or similar. -- 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: