From wtogami at redhat.com Sun May 1 23:42:25 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 May 2005 13:42:25 -1000 Subject: FC4-re0429.0 known bugs? Message-ID: <42756961.4030200@redhat.com> Are the following the result of known bugs? Should I file if unknown? 1) FC3 x86_64 -> FC4-re0429.0 upgrade is extremely screwed. =========================================================== Hardware: 2x1.2GHz Opteron on Tyan motherboard i2o_block SCSI RAID on /dev/i2o/hda Fresh install of FC3 x86_64 "Workstation" and all 244 32bit compat packages. Then upgrade to FC4-re0429.0. a) Grub gets stuck at stage 2 during bootup. http://people.redhat.com/wtogami/temp/chroot-x86-64-segfault.txt b) Rescue mode mounts /mnt/sysimage, but chroot segfaults. http://people.redhat.com/wtogami/temp/packagelist-fc3-fc4-x86-64-upgrade.txt c) rpm reveals that the perl.i386 is still there. Shouldn't we add a special case to Anaconda to blow away perl.i386 on x86_64? We need to get rid of it from all FC3 and RHEL4 anyway. d) FC4 kernel completely failed to install, 2.6.9-1.667.x86_64 is still the only installed kernel. e) Other leftovers like firefox-0.10.1-1.0PR1.20.x86_64 are installed along with the FC4 firefox-1.0.3-2.x86_64 for seemingly no reason. 2) x86_64 Eclipse trouble ========================= libgcj-4.0.0-2 eclipse-ecj-3.1.0_fc-0.M6.12 x86_64 eclipse on 2GHz Athlon64 3200+ takes about 25 seconds to start. /tmp on the x86_64 contains hundreds of zero size files like "workbench.jar.sox3zske.so" [warren at fedora64 tmp]$ ls -l *jar* |wc -l 1156 i386 eclipse on 1.6GHz PentiumM takes about 13 seconds to start. No apparent trouble files dumped into /tmp 3) Metacity New Window focus ============================ In FC3 when you click on the Web Browser launcher, the new window always pops up. In FC4 new windows seem to always pop-under which may be very confusing to users. Was this change intentional? Warren Togami wtogami at redhat.com From wtogami at redhat.com Mon May 2 00:17:47 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 May 2005 14:17:47 -1000 Subject: FC4-re0429.0 known bugs? In-Reply-To: <42756961.4030200@redhat.com> References: <42756961.4030200@redhat.com> Message-ID: <427571AB.9050109@redhat.com> Warren Togami wrote: > Are the following the result of known bugs? Should I file if unknown? > > 1) FC3 x86_64 -> FC4-re0429.0 upgrade is extremely screwed. > =========================================================== > Hardware: 2x1.2GHz Opteron on Tyan motherboard > i2o_block SCSI RAID on /dev/i2o/hda > > Fresh install of FC3 x86_64 "Workstation" and all 244 32bit compat > packages. Then upgrade to FC4-re0429.0. > > a) Grub gets stuck at stage 2 during bootup. Same thing with a fresh install... =( Anybody have any success installing FC4 on /dev/i2o/* devices? Warren Togami wtogami at redhat.com From overholt at redhat.com Mon May 2 01:22:59 2005 From: overholt at redhat.com (Andrew Overholt) Date: Sun, 1 May 2005 21:22:59 -0400 Subject: FC4-re0429.0 known bugs? In-Reply-To: <42756961.4030200@redhat.com> References: <42756961.4030200@redhat.com> Message-ID: <20050502012259.GA31473@redhat.com> * Warren Togami [2005-05-01 19:43]: > > 2) x86_64 Eclipse trouble > ========================= > libgcj-4.0.0-2 > eclipse-ecj-3.1.0_fc-0.M6.12 > > x86_64 eclipse on 2GHz Athlon64 3200+ takes about 25 seconds to start. > /tmp on the x86_64 contains hundreds of zero size files like > "workbench.jar.sox3zske.so" > [warren at fedora64 tmp]$ ls -l *jar* |wc -l > 1156 Hmm. I'm not sure what those files are. I'll find an x86_64 box tomorrow and look into it. Has anybody on fedora-devel-java seen this before? Andrew From wtogami at redhat.com Mon May 2 03:59:40 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 May 2005 17:59:40 -1000 Subject: FC4-re0429.0 known bugs? In-Reply-To: <427571AB.9050109@redhat.com> References: <42756961.4030200@redhat.com> <427571AB.9050109@redhat.com> Message-ID: <4275A5AC.9090006@redhat.com> Warren Togami wrote: > Warren Togami wrote: > >> Are the following the result of known bugs? Should I file if unknown? >> >> 1) FC3 x86_64 -> FC4-re0429.0 upgrade is extremely screwed. >> =========================================================== >> Hardware: 2x1.2GHz Opteron on Tyan motherboard >> i2o_block SCSI RAID on /dev/i2o/hda >> >> Fresh install of FC3 x86_64 "Workstation" and all 244 32bit compat >> packages. Then upgrade to FC4-re0429.0. >> >> a) Grub gets stuck at stage 2 during bootup. > > > Same thing with a fresh install... =( > > Anybody have any success installing FC4 on /dev/i2o/* devices? > Booted into rescue mode, successfully chrooted into /mnt/sysimage (this time after clean install didn't segfault) and 'grub-install /dev/i2o/hda' made grub working again. Anaconda apparently isn't doing something right... Warren From cra at WPI.EDU Mon May 2 10:24:04 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Mon, 2 May 2005 06:24:04 -0400 Subject: FC4-re0429.0 known bugs? In-Reply-To: <4275A5AC.9090006@redhat.com> References: <42756961.4030200@redhat.com> <427571AB.9050109@redhat.com> <4275A5AC.9090006@redhat.com> Message-ID: <20050502102404.GB6771@angus.ind.WPI.EDU> On Sun, May 01, 2005 at 05:59:40PM -1000, Warren Togami wrote: > >Same thing with a fresh install... =( > > > >Anybody have any success installing FC4 on /dev/i2o/* devices? > > > > Booted into rescue mode, successfully chrooted into /mnt/sysimage (this > time after clean install didn't segfault) and 'grub-install > /dev/i2o/hda' made grub working again. Anaconda apparently isn't doing > something right... I'm not surprised. Having read the booty code, there is a hardcoded list of devices that are handled specially. /dev/i2o/* is not among them. These are handled specially due to device/partition naming schemes: /dev/cciss/c0d0p1 /dev/rd/c0d0p1 /dev/ida/c0d0p1 At a glance, these appear to be unsupported block devices: /dev/ataraid/d0p1 /dev/amiraid/ar0p1 /dev/cbd/[a-z] /dev/emd/0p1 /dev/i2o/hda[a-z] /dev/iseries/vda[a-f] /dev/umem/d0p1 /dev/sx8/0p1 From jnovy at redhat.com Mon May 2 12:38:06 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 02 May 2005 14:38:06 +0200 Subject: Duplicated files in the pristine FC4t2 installation Message-ID: <1115037486.29438.54.camel@obelix.redhat.usu> Hello all, I've found some file duplicates when I browsed through the /usr directory tree in the pristine & complete FC4t2 installation what made me curious how many duplicates are there in total. This is not critical, so please take this as something for your information that some files would better be symlinked/hardlinked in order to not to waste disc space without a point. I know there's sometimes no other way that to duplicate a file, but the statistics I have is IMHO rather interesting: 206405 regular files found, 4149 MiB [5468 MiB] 15797 total dupes, 15705 non-zero sized. 96 MiB [161 MiB], 2.325% [2.951%] wasted by dupes, 13906 symlinks, 5042 hardlinks. So that 161 MiB is "wasted" physically in the /usr tree, what is about 3% in total from all the files within the /usr hierarchy. To let this information be somehow worth for the package maintainers, I'm adding a link to the list of all the duplicated files including their sizes and md5 sums and to what package they belong: http://people.redhat.com/jnovy/files/FC4t2-usr-dupes.gz This statistics was done by the "slink" utility I wrote some time ago. It's able to replace duplicates with symbolic links to save disc space [EXPERIMENTAL, but seems to work] or just display a statistics about duplicates for a given directory. If you want to give it a try, get it from: http://people.redhat.com/jnovy/files/slink-0.0.1-pre1.tar.bz2 It's interesting how many GPL "COPYING" clones we have in /usr/share/doc for instance. Unfortunately some of my packages are also affected ;) Regards, Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ The worst evil in the world is refusal to think. From arjanv at redhat.com Mon May 2 12:43:07 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 2 May 2005 14:43:07 +0200 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <1115037486.29438.54.camel@obelix.redhat.usu> References: <1115037486.29438.54.camel@obelix.redhat.usu> Message-ID: <20050502124307.GA16882@devserv.devel.redhat.com> On Mon, May 02, 2005 at 02:38:06PM +0200, Jindrich Novy wrote: > > This statistics was done by the "slink" utility I wrote some time ago. we also ship the hardlink utility, which is probably a tiny bit nicer in that it makes the replacement more transparent for things like rpm From j.w.r.degoede at hhs.nl Mon May 2 12:52:02 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 May 2005 14:52:02 +0200 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <1115037486.29438.54.camel@obelix.redhat.usu> References: <1115037486.29438.54.camel@obelix.redhat.usu> Message-ID: <42762272.1080102@hhs.nl> Hmm, Lots of pyo pyc duplicates, this should be somehow fixed in python can RPM handle hardlinks iow can an rpm contain a file and hardlink to the file instead of 2 copies of the file? If rpm can handle hardlinks then this should be fixable preferrably python should just create a hardlink when the pyc and pyo are the same. About licenses what about a licenses.rpm which gets installed by default which contains most common licenses and which is an obligatory part of the base system. And then just put a ptr to the license in the rpm -qi info? That would also cleanout /usr/share/doc since quite a few dirs there only contain a copy of the GPL / MPL / whatever license Regards, Hans Jindrich Novy wrote: > Hello all, > > I've found some file duplicates when I browsed through the /usr > directory tree in the pristine & complete FC4t2 installation what made > me curious how many duplicates are there in total. This is not critical, > so please take this as something for your information that some files > would better be symlinked/hardlinked in order to not to waste disc space > without a point. I know there's sometimes no other way that to duplicate > a file, but the statistics I have is IMHO rather interesting: > > 206405 regular files found, 4149 MiB [5468 MiB] > 15797 total dupes, 15705 non-zero sized. > 96 MiB [161 MiB], 2.325% [2.951%] wasted by dupes, 13906 symlinks, 5042 > hardlinks. > > So that 161 MiB is "wasted" physically in the /usr tree, what is about > 3% in total from all the files within the /usr hierarchy. > > To let this information be somehow worth for the package maintainers, > I'm adding a link to the list of all the duplicated files including > their sizes and md5 sums and to what package they belong: > > http://people.redhat.com/jnovy/files/FC4t2-usr-dupes.gz > > This statistics was done by the "slink" utility I wrote some time ago. > It's able to replace duplicates with symbolic links to save disc space > [EXPERIMENTAL, but seems to work] or just display a statistics about > duplicates for a given directory. If you want to give it a try, get it > from: > > http://people.redhat.com/jnovy/files/slink-0.0.1-pre1.tar.bz2 > > It's interesting how many GPL "COPYING" clones we have in /usr/share/doc > for instance. Unfortunately some of my packages are also affected ;) > > Regards, > Jindrich > From arjanv at redhat.com Mon May 2 12:58:20 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 02 May 2005 08:58:20 -0400 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <42762272.1080102@hhs.nl> References: <1115037486.29438.54.camel@obelix.redhat.usu> <42762272.1080102@hhs.nl> Message-ID: <1115038700.6098.0.camel@localhost.localdomain> > About licenses what about a licenses.rpm which gets installed by default > which contains most common licenses and which is an obligatory part of > the base system. And then just put a ptr to the license in the rpm -qi > info? That would also cleanout /usr/share/doc since quite a few dirs > there only contain a copy of the GPL / MPL / whatever license problem is that the GPL at least requires you to ship the license with the software. And RPMs get used and for sure distributed outside fedora... -------------- 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 j.w.r.degoede at hhs.nl Mon May 2 13:07:09 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 02 May 2005 15:07:09 +0200 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <1115038700.6098.0.camel@localhost.localdomain> References: <1115037486.29438.54.camel@obelix.redhat.usu> <42762272.1080102@hhs.nl> <1115038700.6098.0.camel@localhost.localdomain> Message-ID: <427625FD.2090408@hhs.nl> Putting on evil hat: I already was afraid that would be used as an argument, taking this over the top glibc-devel and glibc-common don't contain COPYING, only glibc does. That can be explained in 2 ways: -all (L)GPL devel rpms should be modified to include COPYING -we can create a licenses.rpm as long as its Requires: by rpms which fall under one of the licenses in licenses.rpm Regards, Hans Arjan van de Ven wrote: >>About licenses what about a licenses.rpm which gets installed by default >>which contains most common licenses and which is an obligatory part of >>the base system. And then just put a ptr to the license in the rpm -qi >>info? That would also cleanout /usr/share/doc since quite a few dirs >>there only contain a copy of the GPL / MPL / whatever license > > > problem is that the GPL at least requires you to ship the license with > the software. And RPMs get used and for sure distributed outside > fedora... > > > ------------------------------------------------------------------------ > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jnovy at redhat.com Mon May 2 13:09:46 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 02 May 2005 15:09:46 +0200 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <1115038700.6098.0.camel@localhost.localdomain> References: <1115037486.29438.54.camel@obelix.redhat.usu> <42762272.1080102@hhs.nl> <1115038700.6098.0.camel@localhost.localdomain> Message-ID: <1115039386.29438.63.camel@obelix.redhat.usu> On Mon, 2005-05-02 at 08:58 -0400, Arjan van de Ven wrote: > > About licenses what about a licenses.rpm which gets installed by default > > which contains most common licenses and which is an obligatory part of > > the base system. And then just put a ptr to the license in the rpm -qi > > info? That would also cleanout /usr/share/doc since quite a few dirs > > there only contain a copy of the GPL / MPL / whatever license > > problem is that the GPL at least requires you to ship the license with > the software. And RPMs get used and for sure distributed outside > fedora... This wouldn't be a drawback if some utility would search and replace the duplicates in /usr/share/doc for instance after installation of all the selected packages. But I'm not sure if rpm will be happy with it... -- Jindrich Novy , http://people.redhat.com/jnovy/ The worst evil in the world is refusal to think. From katzj at redhat.com Mon May 2 13:50:03 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 02 May 2005 09:50:03 -0400 Subject: FC4-re0429.0 known bugs? In-Reply-To: <20050502102404.GB6771@angus.ind.WPI.EDU> References: <42756961.4030200@redhat.com> <427571AB.9050109@redhat.com> <4275A5AC.9090006@redhat.com> <20050502102404.GB6771@angus.ind.WPI.EDU> Message-ID: <1115041803.3574.74.camel@bree.local.net> On Mon, 2005-05-02 at 06:24 -0400, Chuck R. Anderson wrote: > At a glance, these appear to be unsupported block devices: > > /dev/ataraid/d0p1 > /dev/amiraid/ar0p1 > /dev/cbd/[a-z] > /dev/emd/0p1 Not supported in our kernels or anywhere else in anaconda. > /dev/i2o/hda[a-z] This shouldn't be a problem -- aren't the partitions of the form /dev/i2o/hda2? > /dev/iseries/vda[a-f] iSeries only, you don't really run grub there :-) > /dev/umem/d0p1 See the first set of stuff. > /dev/sx8/0p1 Added in CVS. Jeremy From cra at WPI.EDU Mon May 2 18:50:17 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Mon, 2 May 2005 14:50:17 -0400 Subject: FC4-re0429.0 known bugs? In-Reply-To: <1115041803.3574.74.camel@bree.local.net> References: <42756961.4030200@redhat.com> <427571AB.9050109@redhat.com> <4275A5AC.9090006@redhat.com> <20050502102404.GB6771@angus.ind.WPI.EDU> <1115041803.3574.74.camel@bree.local.net> Message-ID: <20050502185017.GC1203@angus.ind.WPI.EDU> On Mon, May 02, 2005 at 09:50:03AM -0400, Jeremy Katz wrote: > > /dev/i2o/hda[a-z] > This shouldn't be a problem -- aren't the partitions of the > form /dev/i2o/hda2? I have no actual knowledge of these devices myself. I read in /etc/makedev.d/linux-2.6.x: b $STORAGE 80 0 1 16 i2o/hda b $STORAGE 80 16 1 16 i2o/hdb b $STORAGE 80 32 1 16 i2o/hdc b $STORAGE 80 48 1 16 i2o/hdd b $STORAGE 80 64 1 16 i2o/hde b $STORAGE 80 80 1 16 i2o/hdf b $STORAGE 80 96 1 16 i2o/hdg b $STORAGE 80 112 1 16 i2o/hdh b $STORAGE 80 128 1 16 i2o/hdi b $STORAGE 80 144 1 16 i2o/hdj b $STORAGE 80 160 1 16 i2o/hdk b $STORAGE 80 176 1 16 i2o/hdl b $STORAGE 80 192 1 16 i2o/hdm b $STORAGE 80 208 1 16 i2o/hdn b $STORAGE 80 224 1 16 i2o/hdo b $STORAGE 80 240 1 16 i2o/hdp b $STORAGE 81 0 1 16 i2o/hdq b $STORAGE 81 16 1 16 i2o/hdr b $STORAGE 81 32 1 16 i2o/hds b $STORAGE 81 48 1 16 i2o/hdt b $STORAGE 81 64 1 16 i2o/hdu b $STORAGE 81 80 1 16 i2o/hdv b $STORAGE 81 96 1 16 i2o/hdw b $STORAGE 81 112 1 16 i2o/hdx b $STORAGE 81 128 1 16 i2o/hdy b $STORAGE 81 144 1 16 i2o/hdz b $STORAGE 81 160 1 16 i2o/hdaa b $STORAGE 81 176 1 16 i2o/hdab b $STORAGE 81 192 1 16 i2o/hdac b $STORAGE 81 208 1 16 i2o/hdad b $STORAGE 81 224 1 16 i2o/hdae b $STORAGE 81 240 1 16 i2o/hdaf ... and interpreted this to mean partitions of the form i2o/hd?[a-z] I did find this description in the kernel Documentation/devices.txt: 80 block I2O hard disk 0 = /dev/i2o/hda First I2O hard disk, whole disk 16 = /dev/i2o/hdb Second I2O hard disk, whole disk ... 240 = /dev/i2o/hdp 16th I2O hard disk, whole disk Partitions are handled in the same way as for IDE disks (see major number 3) except that the limit on partitions is 15. so maybe there is a bug in MAKEDEV? > > /dev/sx8/0p1 > Added in CVS. Excellent. From pjones at redhat.com Mon May 2 19:19:10 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 02 May 2005 15:19:10 -0400 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <42762272.1080102@hhs.nl> References: <1115037486.29438.54.camel@obelix.redhat.usu> <42762272.1080102@hhs.nl> Message-ID: <1115061550.12093.0.camel@localhost.localdomain> On Mon, 2005-05-02 at 14:52 +0200, Hans de Goede wrote: > Hmm, > > Lots of pyo pyc duplicates, this should be somehow fixed in python can > RPM handle hardlinks iow can an rpm contain a file and hardlink to the > file instead of 2 copies of the file? > > If rpm can handle hardlinks then this should be fixable preferrably > python should just create a hardlink when the pyc and pyo are the same. You could make rpm run "hardlinks" on a directory, but the results are pretty painful -- you wind up running it per-package, and that means everything takes forever. -- Peter From arjanv at redhat.com Mon May 2 19:23:46 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 2 May 2005 21:23:46 +0200 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <1115061550.12093.0.camel@localhost.localdomain> References: <1115037486.29438.54.camel@obelix.redhat.usu> <42762272.1080102@hhs.nl> <1115061550.12093.0.camel@localhost.localdomain> Message-ID: <20050502192346.GA19481@devserv.devel.redhat.com> On Mon, May 02, 2005 at 03:19:10PM -0400, Peter Jones wrote: > On Mon, 2005-05-02 at 14:52 +0200, Hans de Goede wrote: > > Hmm, > > > > Lots of pyo pyc duplicates, this should be somehow fixed in python can > > RPM handle hardlinks iow can an rpm contain a file and hardlink to the > > file instead of 2 copies of the file? > > > > If rpm can handle hardlinks then this should be fixable preferrably > > python should just create a hardlink when the pyc and pyo are the same. > > You could make rpm run "hardlinks" on a directory, but the results are > pretty painful -- you wind up running it per-package, and that means > everything takes forever. or run it from cron.weekly on /usr/share/doc ;) From pjones at redhat.com Mon May 2 19:25:00 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 02 May 2005 15:25:00 -0400 Subject: FC4-re0429.0 known bugs? In-Reply-To: <20050502185017.GC1203@angus.ind.WPI.EDU> References: <42756961.4030200@redhat.com> <427571AB.9050109@redhat.com> <4275A5AC.9090006@redhat.com> <20050502102404.GB6771@angus.ind.WPI.EDU> <1115041803.3574.74.camel@bree.local.net> <20050502185017.GC1203@angus.ind.WPI.EDU> Message-ID: <1115061900.12093.4.camel@localhost.localdomain> On Mon, 2005-05-02 at 14:50 -0400, Chuck R. Anderson wrote: [...] > b $STORAGE 80 0 1 16 i2o/hda > b $STORAGE 80 16 1 16 i2o/hdb [...] > b $STORAGE 81 128 1 16 i2o/hdy > b $STORAGE 81 144 1 16 i2o/hdz > b $STORAGE 81 160 1 16 i2o/hdaa > b $STORAGE 81 176 1 16 i2o/hdab [...] > and interpreted this to mean partitions of the form i2o/hd?[a-z] That's "if you have 27 disks, the 27th is named hdaa, and its first partition is hdaa1". -- Peter From Markus.Lidel at shadowconnect.com Mon May 2 19:29:58 2005 From: Markus.Lidel at shadowconnect.com (Markus Lidel) Date: Mon, 02 May 2005 21:29:58 +0200 Subject: FC4-re0429.0 known bugs? In-Reply-To: <20050502185017.GC1203@angus.ind.WPI.EDU> References: <42756961.4030200@redhat.com> <427571AB.9050109@redhat.com> <4275A5AC.9090006@redhat.com> <20050502102404.GB6771@angus.ind.WPI.EDU> <1115041803.3574.74.camel@bree.local.net> <20050502185017.GC1203@angus.ind.WPI.EDU> Message-ID: <42767FB6.5070001@shadowconnect.com> Hello, Chuck R. Anderson wrote: > On Mon, May 02, 2005 at 09:50:03AM -0400, Jeremy Katz wrote: >>>/dev/i2o/hda[a-z] >>This shouldn't be a problem -- aren't the partitions of the >>form /dev/i2o/hda2? > I have no actual knowledge of these devices myself. > I read in /etc/makedev.d/linux-2.6.x: > b $STORAGE 80 0 1 16 i2o/hda > b $STORAGE 80 16 1 16 i2o/hdb > b $STORAGE 80 32 1 16 i2o/hdc > b $STORAGE 80 48 1 16 i2o/hdd > b $STORAGE 80 64 1 16 i2o/hde > b $STORAGE 80 80 1 16 i2o/hdf > b $STORAGE 80 96 1 16 i2o/hdg > b $STORAGE 80 112 1 16 i2o/hdh > b $STORAGE 80 128 1 16 i2o/hdi > b $STORAGE 80 144 1 16 i2o/hdj > b $STORAGE 80 160 1 16 i2o/hdk > b $STORAGE 80 176 1 16 i2o/hdl > b $STORAGE 80 192 1 16 i2o/hdm > b $STORAGE 80 208 1 16 i2o/hdn > b $STORAGE 80 224 1 16 i2o/hdo > b $STORAGE 80 240 1 16 i2o/hdp > b $STORAGE 81 0 1 16 i2o/hdq > b $STORAGE 81 16 1 16 i2o/hdr > b $STORAGE 81 32 1 16 i2o/hds > b $STORAGE 81 48 1 16 i2o/hdt > b $STORAGE 81 64 1 16 i2o/hdu > b $STORAGE 81 80 1 16 i2o/hdv > b $STORAGE 81 96 1 16 i2o/hdw > b $STORAGE 81 112 1 16 i2o/hdx > b $STORAGE 81 128 1 16 i2o/hdy > b $STORAGE 81 144 1 16 i2o/hdz > b $STORAGE 81 160 1 16 i2o/hdaa > b $STORAGE 81 176 1 16 i2o/hdab > b $STORAGE 81 192 1 16 i2o/hdac > b $STORAGE 81 208 1 16 i2o/hdad > b $STORAGE 81 224 1 16 i2o/hdae > b $STORAGE 81 240 1 16 i2o/hdaf > ... > > and interpreted this to mean partitions of the form i2o/hd?[a-z] It's like IDE /dev/i2o/hda, /dev/i2o/hdb, ... are the harddisks, and /dev/i2o/hda1, /dev/i2o/hda2, ... are the partitions on the first harddisk, /dev/i2o/hdb1, /dev/i2o/hdb2, ... are the partitions on the second harddisk, and so on... Best regards, Markus Lidel From mharris at redhat.com Mon May 2 19:41:17 2005 From: mharris at redhat.com (Mike A. Harris) Date: Mon, 02 May 2005 15:41:17 -0400 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <20050502192346.GA19481@devserv.devel.redhat.com> References: <1115037486.29438.54.camel@obelix.redhat.usu> <42762272.1080102@hhs.nl> <1115061550.12093.0.camel@localhost.localdomain> <20050502192346.GA19481@devserv.devel.redhat.com> Message-ID: <4276825D.7090204@redhat.com> Arjan van de Ven wrote: > On Mon, May 02, 2005 at 03:19:10PM -0400, Peter Jones wrote: > >>On Mon, 2005-05-02 at 14:52 +0200, Hans de Goede wrote: >> >>>Hmm, >>> >>>Lots of pyo pyc duplicates, this should be somehow fixed in python can >>>RPM handle hardlinks iow can an rpm contain a file and hardlink to the >>>file instead of 2 copies of the file? >>> >>>If rpm can handle hardlinks then this should be fixable preferrably >>>python should just create a hardlink when the pyc and pyo are the same. >> >>You could make rpm run "hardlinks" on a directory, but the results are >>pretty painful -- you wind up running it per-package, and that means >>everything takes forever. > > > or run it from cron.weekly on /usr/share/doc ;) God please no. We already have too many cron jobs that turn a machine into a slug. I think it is 100% wrong to mark files as duplicates because they are the same "now". There is no guarantee they will be the same in a future update. Excluding a GPL license COPYING file from one package and linking it to another central copy fails the second someone decides to use GPLv3 for that package. Or if they add text to the top of the file or something. It is bad practice to be doing this with license files, for almost zero gain. A few months ago Warren scanned the entire OS to see what would be gained if we were to do what is being proposed here. The results were negligible. Lets take 10 steps back and try to see the forest for a minute, ignoring the trees for the time being. If the goal is to make the distribution take up less space - lets focus on analyzing what exactly is taking up the most space on the distribution after install. Find the top 10 space consumers, and begin analyzing how we might be able to reduce the space they're using. I suspect solving that high-level problem will result in a disk space savings 10-20 times any savings we might gain from hardlinking GPL "COPYING" files. Let's focus on the real problem rather than coming up with solutions and then looking for problems we can solve with them. From pjones at redhat.com Mon May 2 20:12:50 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 02 May 2005 16:12:50 -0400 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: <4276825D.7090204@redhat.com> References: <1115037486.29438.54.camel@obelix.redhat.usu> <42762272.1080102@hhs.nl> <1115061550.12093.0.camel@localhost.localdomain> <20050502192346.GA19481@devserv.devel.redhat.com> <4276825D.7090204@redhat.com> Message-ID: <1115064770.12093.35.camel@localhost.localdomain> On Mon, 2005-05-02 at 15:41 -0400, Mike A. Harris wrote: > I think it is 100% wrong to mark files as duplicates because > they are the same "now". There is no guarantee they will be > the same in a future update. That doesn't matter, updating has the nice property of running unlink(2) on it if it's not supposed to be the same any more. But I think the whole problem is silly as well, FWIW. -- Peter From roland at redhat.com Mon May 2 20:27:08 2005 From: roland at redhat.com (Roland McGrath) Date: Mon, 2 May 2005 13:27:08 -0700 Subject: Duplicated files in the pristine FC4t2 installation In-Reply-To: Peter Jones's message of Monday, 2 May 2005 16:12:50 -0400 <1115064770.12093.35.camel@localhost.localdomain> Message-ID: <200505022027.j42KR8mM022835@magilla.sf.frob.com> > But I think the whole problem is silly as well, FWIW. When Warren brought this up on IRC a while back, I wrote the following script and rand it on a rawhide everything install. This fails to take into account files that are already hardlinked, so and its results might well be significantly inflated. (Someone who cares could hack it further to check installed names of a duplicate file for being the same inode.) Total 408578931 bytes in 43107 inodes That's a max of < 400M on an install that is something 8.5-9G. So the issue is worth at most on the order of 5% of disk space, and that is probably a very high estimate. rpm -qa --qf '[%{FILEMD5S} %{FILENAMES} %{FILESIZES} %{SOURCERPM}\n]' | awk ' NF < 4 { next } # directory { md5_name[$1] = $2; md5_srpm[$1] = $4; info = $2 " " $4; if ($1 in sizes) { if ($3 != sizes[$1]) print "!!!", $1 ":", info, "VS", md5[info] } else { sizes[$1] = $3; } if ($1 in md5) { if (info == md5[$1]) next; for (i = 1; i < dups[$1]; ++i) if (dupinfo[$1 "," i] == info) next; dups[$1]++; dupinfo[$1 "," dups[$1]] = info; } else { md5[$1] = info; } } END { dupsize = dupcount = 0; for (sum in dups) { n = dups[sum]; dupcount += n; dupsize += n * sizes[sum]; print n, "dups:", sum, " ==> ", (n * sizes[sum]); print "\t" md5[sum]; for (i = 1; i <= n; ++i) print "\t" dupinfo[sum "," i]; } print "Total", dupsize, "bytes in", dupcount, "inodes"; } ' From notting at redhat.com Fri May 6 19:03:42 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 6 May 2005 15:03:42 -0400 Subject: dev86 removed from Core Message-ID: <20050506190342.GA353@nostromo.devel.redhat.com> dev86 was removed from Core as of last night, as nothing requires it to build now. There do not appear to be any Extras packages that require it to build as of a quick check; however, if you maintain a package in Extras that does a) make sure you have proper build reqs :) b) you may want to consider porting it to the stock tools, or including dev86 in Extras Bill From skvidal at phy.duke.edu Sat May 7 14:59:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 10:59:43 -0400 Subject: Extras Builds Message-ID: <1115477983.15593.36.camel@cutter> Hi Everyone, This was actually opened up for everyone yesterday but I found a couple more problems and wanted to get them addressed before I announced it. 'make build' is open. After you check in a package and get it approved you should run 'make tag' to tag the package then run 'make build TARGET=distrover' to get it built. so for a Fedora Extras 3 package you'd run: make build TARGET=FC3 for a Fedora Extras Development package you'd run: make build TARGET=development eventually, once FC4 is released you'd run: make build TARGET=FC4 you should make sure you're in the correct branch directory, of course. The only thing to look out for is conflicts in the 'tobuild' file. Right now this file is updated via the 'make build' command and checked into cvs. In the very near future it will be submitting the job to an xml-rpc server which will store the build request in a db. -sv From ivazquez at ivazquez.net Sat May 7 15:24:42 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 07 May 2005 11:24:42 -0400 Subject: Extras Builds In-Reply-To: <1115477983.15593.36.camel@cutter> References: <1115477983.15593.36.camel@cutter> Message-ID: <1115479482.7124.13.camel@ignacio.ignacio.lan> On Sat, 2005-05-07 at 10:59 -0400, seth vidal wrote: > 'make build' is open. > > After you check in a package and get it approved you should run 'make > tag' to tag the package then run 'make build TARGET=distrover' to get it > built. > > so for a Fedora Extras 3 package you'd run: > make build TARGET=FC3 > > for a Fedora Extras Development package you'd run: > make build TARGET=development > > > eventually, once FC4 is released you'd run: > make build TARGET=FC4 > > you should make sure you're in the correct branch directory, of course. No default based on what branch you're in? Excellent job, BTW. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 skvidal at phy.duke.edu Sat May 7 15:48:29 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 11:48:29 -0400 Subject: Extras Builds In-Reply-To: <1115479482.7124.13.camel@ignacio.ignacio.lan> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> Message-ID: <1115480909.15593.49.camel@cutter> > No default based on what branch you're in? no. > Excellent job, BTW. thanks, though the 'make build' Makefile magic was setup by jeremy katz. The code that reads and handles what is in 'tobuild' is what I did. -sv From skvidal at phy.duke.edu Sat May 7 16:11:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 12:11:22 -0400 Subject: Builds for FC3 Message-ID: <1115482283.15593.61.camel@cutter> Hey guys, before you request builds for FC3 - make sure it's not already built. look here: http://extras64.linux.duke.edu/needsign/3/ and http://extras64.linux.duke.edu/failed/3/ Thanks! -sv From ed at eh3.com Sat May 7 17:16:34 2005 From: ed at eh3.com (Ed Hill) Date: Sat, 07 May 2005 13:16:34 -0400 Subject: Builds for FC3 In-Reply-To: <1115482283.15593.61.camel@cutter> References: <1115482283.15593.61.camel@cutter> Message-ID: <1115486194.24408.242.camel@ernie> On Sat, 2005-05-07 at 12:11 -0400, seth vidal wrote: > Hey guys, > before you request builds for FC3 - make sure it's not already built. > > look here: > http://extras64.linux.duke.edu/needsign/3/ Hi Seth, Very nice! Thank you!!! And I was wondering: what has to happen to get the packages in the "needsign" group above into the yum repo? Do we have to request anything or is it automatic? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From katzj at redhat.com Sat May 7 18:41:04 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 07 May 2005 14:41:04 -0400 Subject: Extras Builds In-Reply-To: <1115479482.7124.13.camel@ignacio.ignacio.lan> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> Message-ID: <1115491264.3302.80.camel@bree.local.net> On Sat, 2005-05-07 at 11:24 -0400, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-05-07 at 10:59 -0400, seth vidal wrote: > > eventually, once FC4 is released you'd run: > > make build TARGET=FC4 > > > > you should make sure you're in the correct branch directory, of course. > > No default based on what branch you're in? Not at present... patches accepted to add that functionality to Makefile.common. Or I'll get around to it eventually :-) Jeremy From ville.skytta at iki.fi Sat May 7 20:26:16 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 07 May 2005 23:26:16 +0300 Subject: Extras Builds In-Reply-To: <1115477983.15593.36.camel@cutter> References: <1115477983.15593.36.camel@cutter> Message-ID: <1115497576.9556.10.camel@bobcat.mine.nu> On Sat, 2005-05-07 at 10:59 -0400, seth vidal wrote: > 'make build' is open. Does the system notify the submitter when the build request has been processed and the build started/finished? If not, is there some other way to track the builds? I requested a build of perl-Module-Build some time ago, no notification received yet nor is the package in failed or needsign. From gemi at bluewin.ch Sat May 7 20:33:14 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 07 May 2005 22:33:14 +0200 Subject: Builds for FC3 In-Reply-To: <1115482283.15593.61.camel@cutter> References: <1115482283.15593.61.camel@cutter> Message-ID: <1115497994.12045.1.camel@scriabin.tannenrauch.ch> On Sat, 2005-05-07 at 12:11 -0400, seth vidal wrote: > Hey guys, > before you request builds for FC3 - make sure it's not already built. > > look here: > > http://extras64.linux.duke.edu/needsign/3/ What is to do for these packages? > > and > http://extras64.linux.duke.edu/failed/3/ gcl is in there but the log does not show any errors, and the rpms are built. Is ../Extras_2fFC3Status now obsolete? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From wtogami at redhat.com Sat May 7 20:39:01 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 07 May 2005 10:39:01 -1000 Subject: Extras Builds In-Reply-To: <1115477983.15593.36.camel@cutter> References: <1115477983.15593.36.camel@cutter> Message-ID: <427D2765.1020106@redhat.com> seth vidal wrote: > Hi Everyone, > This was actually opened up for everyone yesterday but I found a couple > more problems and wanted to get them addressed before I announced it. > > 'make build' is open. > > After you check in a package and get it approved you should run 'make > tag' to tag the package then run 'make build TARGET=distrover' to get it > built. > > so for a Fedora Extras 3 package you'd run: > make build TARGET=FC3 > > for a Fedora Extras Development package you'd run: > make build TARGET=development > > > eventually, once FC4 is released you'd run: > make build TARGET=FC4 > Why does it not match the lowercase disttag of "fc3" or "fc4"? It is also different from the cvs "branches" of "FC-3" and "FC-4". So then we have to remember three different names and use the right one in different circumstances. make build TARGET=fc3 make build TARGET=development make build TARGET=fc4 Can we instead use this? Warren Togami wtogami at redhat.com From ville.skytta at iki.fi Sat May 7 20:46:31 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 07 May 2005 23:46:31 +0300 Subject: Extras Builds In-Reply-To: <427D2765.1020106@redhat.com> References: <1115477983.15593.36.camel@cutter> <427D2765.1020106@redhat.com> Message-ID: <1115498791.9556.13.camel@bobcat.mine.nu> On Sat, 2005-05-07 at 10:39 -1000, Warren Togami wrote: > make build TARGET=fc3 > make build TARGET=development > make build TARGET=fc4 > > Can we instead use this? Using the CVS "branch" names would make more sense to me. At least that should be easier to implement later when someone makes the target to default to the branch where the build request was submitted in, no need for any mappings there. From wtogami at redhat.com Sat May 7 20:54:38 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 07 May 2005 10:54:38 -1000 Subject: Extras Builds In-Reply-To: <1115498791.9556.13.camel@bobcat.mine.nu> References: <1115477983.15593.36.camel@cutter> <427D2765.1020106@redhat.com> <1115498791.9556.13.camel@bobcat.mine.nu> Message-ID: <427D2B0E.5060104@redhat.com> Ville Skytt? wrote: > On Sat, 2005-05-07 at 10:39 -1000, Warren Togami wrote: > > >>make build TARGET=fc3 >>make build TARGET=development >>make build TARGET=fc4 >> >>Can we instead use this? > > > Using the CVS "branch" names would make more sense to me. At least that > should be easier to implement later when someone makes the target to > default to the branch where the build request was submitted in, no need > for any mappings there. > Either matching the disttag or CVS "branch" names is good, I don't care which. Just please don't introduce a 3rd arbitrary mapping. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Sat May 7 21:44:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 23:44:34 +0200 Subject: Builds for FC3 In-Reply-To: <1115497994.12045.1.camel@scriabin.tannenrauch.ch> References: <1115482283.15593.61.camel@cutter> <1115497994.12045.1.camel@scriabin.tannenrauch.ch> Message-ID: <20050507234434.4d9ce712.bugs.michael@gmx.net> On Sat, 07 May 2005 22:33:14 +0200, G?rard Milmeister wrote: > > and > > http://extras64.linux.duke.edu/failed/3/ > gcl is in there but the log does not show any errors, and the rpms are > built. No. x86_64 failed: http://extras64.linux.duke.edu/failed/3/gcl/2.6.6-2/x86_64/ From bugs.michael at gmx.net Sat May 7 21:46:00 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 7 May 2005 23:46:00 +0200 Subject: Extras Builds In-Reply-To: <1115497576.9556.10.camel@bobcat.mine.nu> References: <1115477983.15593.36.camel@cutter> <1115497576.9556.10.camel@bobcat.mine.nu> Message-ID: <20050507234600.6d094934.bugs.michael@gmx.net> On Sat, 07 May 2005 23:26:16 +0300, Ville Skytt? wrote: > On Sat, 2005-05-07 at 10:59 -0400, seth vidal wrote: > > > 'make build' is open. > > Does the system notify the submitter when the build request has been > processed and the build started/finished? Yes, I received a mail for a successful build (which had been reported as failed before) and a failed build. That was after several hours, though. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1258_FC4 loadavg: 1.11 1.25 2.13 From skvidal at phy.duke.edu Sat May 7 22:44:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 18:44:07 -0400 Subject: Extras Builds In-Reply-To: <1115498791.9556.13.camel@bobcat.mine.nu> References: <1115477983.15593.36.camel@cutter> <427D2765.1020106@redhat.com> <1115498791.9556.13.camel@bobcat.mine.nu> Message-ID: <1115505847.15593.63.camel@cutter> > Using the CVS "branch" names would make more sense to me. At least that > should be easier to implement later when someone makes the target to > default to the branch where the build request was submitted in, no need > for any mappings there. > Guess what? it's a dict. It has all of them in there. Go read the code! It's in cvs. targetdict = { 'fc-3': '3', 'devel':'development', '3': '3', 'development': 'development', 'fc3': '3', 'rawhide': 'development'} TADA! that's it. -sv From skvidal at phy.duke.edu Sat May 7 22:45:29 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 18:45:29 -0400 Subject: Extras Builds In-Reply-To: <20050507234600.6d094934.bugs.michael@gmx.net> References: <1115477983.15593.36.camel@cutter> <1115497576.9556.10.camel@bobcat.mine.nu> <20050507234600.6d094934.bugs.michael@gmx.net> Message-ID: <1115505929.15593.65.camel@cutter> > Yes, I received a mail for a successful build (which had been reported as > failed before) and a failed build. That was after several hours, though. It builds them as fast as it can. If you'd like to provide faster machines I'm sure we could build them much more quickly. -sv From skvidal at phy.duke.edu Sat May 7 22:46:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 07 May 2005 18:46:57 -0400 Subject: Builds for FC3 In-Reply-To: <1115486194.24408.242.camel@ernie> References: <1115482283.15593.61.camel@cutter> <1115486194.24408.242.camel@ernie> Message-ID: <1115506017.15593.67.camel@cutter> On Sat, 2005-05-07 at 13:16 -0400, Ed Hill wrote: > On Sat, 2005-05-07 at 12:11 -0400, seth vidal wrote: > > Hey guys, > > before you request builds for FC3 - make sure it's not already built. > > > > look here: > > http://extras64.linux.duke.edu/needsign/3/ > > > Hi Seth, > > Very nice! Thank you!!! > > And I was wondering: what has to happen to get the packages in the > "needsign" group above into the yum repo? Do we have to request > anything or is it automatic? it gets pushed when one of the people who have signing authority get around to it. Right now it's just me but I'll be opening the machine up to the restricted ips of the other signers 'soon'. -sv From ivazquez at ivazquez.net Sun May 8 10:53:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 06:53:16 -0400 Subject: Extras Builds In-Reply-To: <1115491264.3302.80.camel@bree.local.net> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> <1115491264.3302.80.camel@bree.local.net> Message-ID: <1115549596.13384.15.camel@ignacio.ignacio.lan> On Sat, 2005-05-07 at 14:41 -0400, Jeremy Katz wrote: > On Sat, 2005-05-07 at 11:24 -0400, Ignacio Vazquez-Abrams wrote: > > On Sat, 2005-05-07 at 10:59 -0400, seth vidal wrote: > > > eventually, once FC4 is released you'd run: > > > make build TARGET=FC4 > > > > > > you should make sure you're in the correct branch directory, of course. > > > > No default based on what branch you're in? > > Not at present... patches accepted to add that functionality to > Makefile.common. Or I'll get around to it eventually :-) Here's a prelim patch that handles both build and disttags. Feel free to slice-and-dice as desired. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: common-build-dist.patch Type: text/x-patch Size: 2397 bytes Desc: URL: -------------- 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 ivazquez at ivazquez.net Sun May 8 11:27:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 May 2005 07:27:35 -0400 Subject: Extras Builds In-Reply-To: <1115549596.13384.15.camel@ignacio.ignacio.lan> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> <1115491264.3302.80.camel@bree.local.net> <1115549596.13384.15.camel@ignacio.ignacio.lan> Message-ID: <1115551655.12319.2.camel@ignacio.ignacio.lan> On Sun, 2005-05-08 at 06:53 -0400, Ignacio Vazquez-Abrams wrote: > Here's a prelim patch that handles both build and disttags. Feel free to > slice-and-dice as desired. Whoops. The parameters to $(word) for TARGET et al should be 1 less than they are. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 gemi at bluewin.ch Mon May 9 12:30:23 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 09 May 2005 14:30:23 +0200 Subject: [Fwd: Prep Error: graveman-0_3_11-2 on 3] Message-ID: <1115641823.12919.0.camel@scriabin.tannenrauch.ch> -------- Forwarded Message -------- > From: buildsys at fedoraproject.org > To: gemi at fedora.redhat.com > Subject: Prep Error: graveman-0_3_11-2 on 3 > Date: Mon, 9 May 2005 05:23:49 -0400 (EDT) > could not check out graveman-0_3_11-2 from 3 - output was: > cvs [checkout aborted]: no such tag graveman-0_3_11-2 I just cannot get it to build. It seems to tagged correctly, as far as 'make tag' reports, but 'make build TARGET=FC3' results in the above error. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From ivazquez at ivazquez.net Mon May 9 13:10:52 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 09 May 2005 09:10:52 -0400 Subject: [Fwd: Prep Error: graveman-0_3_11-2 on 3] In-Reply-To: <1115641823.12919.0.camel@scriabin.tannenrauch.ch> References: <1115641823.12919.0.camel@scriabin.tannenrauch.ch> Message-ID: <1115644252.21984.25.camel@ignacio.ignacio.lan> On Mon, 2005-05-09 at 14:30 +0200, G?rard Milmeister wrote: > -------- Forwarded Message -------- > > From: buildsys at fedoraproject.org > > To: gemi at fedora.redhat.com > > Subject: Prep Error: graveman-0_3_11-2 on 3 > > Date: Mon, 9 May 2005 05:23:49 -0400 (EDT) > > could not check out graveman-0_3_11-2 from 3 - output was: > > cvs [checkout aborted]: no such tag graveman-0_3_11-2 > I just cannot get it to build. > It seems to tagged correctly, as far as 'make tag' reports, > but 'make build TARGET=FC3' results in the above error. I can't find any such tag anywhere in CVS. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 gemi at bluewin.ch Mon May 9 14:54:22 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 09 May 2005 16:54:22 +0200 Subject: [Fwd: Prep Error: graveman-0_3_11-2 on 3] In-Reply-To: <1115644252.21984.25.camel@ignacio.ignacio.lan> References: <1115641823.12919.0.camel@scriabin.tannenrauch.ch> <1115644252.21984.25.camel@ignacio.ignacio.lan> Message-ID: <1115650462.13594.0.camel@scriabin.tannenrauch.ch> On Mon, 2005-05-09 at 09:10 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2005-05-09 at 14:30 +0200, G?rard Milmeister wrote: > > -------- Forwarded Message -------- > > > From: buildsys at fedoraproject.org > > > To: gemi at fedora.redhat.com > > > Subject: Prep Error: graveman-0_3_11-2 on 3 > > > Date: Mon, 9 May 2005 05:23:49 -0400 (EDT) > > > could not check out graveman-0_3_11-2 from 3 - output was: > > > cvs [checkout aborted]: no such tag graveman-0_3_11-2 > > I just cannot get it to build. > > It seems to tagged correctly, as far as 'make tag' reports, > > but 'make build TARGET=FC3' results in the above error. > > I can't find any such tag anywhere in CVS. When I do a 'make tag' in the FC-3 directory i get: cvs tag -c graveman-0_3_11-2 ERROR: Tag graveman-0_3_11-2 has been already created. The following tags have been created so far graveman-0_3_8-1:devel:gemi:1109453957 graveman-0_3_8-2:FC-3:gemi:1110066000 graveman-0_3_11-1:FC-3:skvidal:1115427972 graveman-0_3_11-2:FC-3:gemi:1115497616 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From bugs.michael at gmx.net Mon May 9 15:09:44 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 9 May 2005 17:09:44 +0200 Subject: [Fwd: Prep Error: graveman-0_3_11-2 on 3] In-Reply-To: <1115650462.13594.0.camel@scriabin.tannenrauch.ch> References: <1115641823.12919.0.camel@scriabin.tannenrauch.ch> <1115644252.21984.25.camel@ignacio.ignacio.lan> <1115650462.13594.0.camel@scriabin.tannenrauch.ch> Message-ID: <20050509170944.2bc98273.bugs.michael@gmx.net> On Mon, 09 May 2005 16:54:22 +0200, G?rard Milmeister wrote: > On Mon, 2005-05-09 at 09:10 -0400, Ignacio Vazquez-Abrams wrote: > > On Mon, 2005-05-09 at 14:30 +0200, G?rard Milmeister wrote: > > > -------- Forwarded Message -------- > > > > From: buildsys at fedoraproject.org > > > > To: gemi at fedora.redhat.com > > > > Subject: Prep Error: graveman-0_3_11-2 on 3 > > > > Date: Mon, 9 May 2005 05:23:49 -0400 (EDT) > > > > could not check out graveman-0_3_11-2 from 3 - output was: > > > > cvs [checkout aborted]: no such tag graveman-0_3_11-2 > > > I just cannot get it to build. > > > It seems to tagged correctly, as far as 'make tag' reports, > > > but 'make build TARGET=FC3' results in the above error. > > > > I can't find any such tag anywhere in CVS. > When I do a 'make tag' in the FC-3 directory i get: > cvs tag -c graveman-0_3_11-2 > ERROR: Tag graveman-0_3_11-2 has been already created. > The following tags have been created so far > graveman-0_3_8-1:devel:gemi:1109453957 > graveman-0_3_8-2:FC-3:gemi:1110066000 > graveman-0_3_11-1:FC-3:skvidal:1115427972 > graveman-0_3_11-2:FC-3:gemi:1115497616 > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 Fixed manually. Tag is present now. Double-check with: cvs co -r graveman-0_3_11-2 graveman From katzj at redhat.com Mon May 9 19:13:09 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 09 May 2005 15:13:09 -0400 Subject: Extras Builds In-Reply-To: <1115549596.13384.15.camel@ignacio.ignacio.lan> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> <1115491264.3302.80.camel@bree.local.net> <1115549596.13384.15.camel@ignacio.ignacio.lan> Message-ID: <1115665989.9762.73.camel@bree.local.net> On Sun, 2005-05-08 at 06:53 -0400, Ignacio Vazquez-Abrams wrote: > Here's a prelim patch that handles both build and disttags. Feel free to > slice-and-dice as desired. spot cleaned it up a little bit (moved the common dir stuff to the top of Makefile.common so that it would work :-) and I've now applied it. Specifying TARGET= should still work if you want, but this can make the default case simpler. Thanks for taking a crack at this Jeremy From jwboyer at jdub.homelinux.org Mon May 9 19:28:08 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 9 May 2005 14:28:08 -0500 Subject: Extras Builds In-Reply-To: <1115665989.9762.73.camel@bree.local.net> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> <1115491264.3302.80.camel@bree.local.net> <1115549596.13384.15.camel@ignacio.ignacio.lan> <1115665989.9762.73.camel@bree.local.net> Message-ID: <20050509192808.GA6704@yoda.jdub.homelinux.org> On Mon, May 09, 2005 at 03:13:09PM -0400, Jeremy Katz wrote: > On Sun, 2005-05-08 at 06:53 -0400, Ignacio Vazquez-Abrams wrote: > > Here's a prelim patch that handles both build and disttags. Feel free to > > slice-and-dice as desired. > > spot cleaned it up a little bit (moved the common dir stuff to the top > of Makefile.common so that it would work :-) and I've now applied it. > Specifying TARGET= should still work if you want, but this can make the > default case simpler. > > Thanks for taking a crack at this Does this mean that maintainers can now remove any hard-coded %{dist} and %{fedora} macros they have in the spec files? josh From tcallawa at redhat.com Mon May 9 19:51:32 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 09 May 2005 14:51:32 -0500 Subject: Extras Builds In-Reply-To: <20050509192808.GA6704@yoda.jdub.homelinux.org> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> <1115491264.3302.80.camel@bree.local.net> <1115549596.13384.15.camel@ignacio.ignacio.lan> <1115665989.9762.73.camel@bree.local.net> <20050509192808.GA6704@yoda.jdub.homelinux.org> Message-ID: <1115668292.3017.96.camel@localhost.localdomain> On Mon, 2005-05-09 at 14:28 -0500, Josh Boyer wrote: > On Mon, May 09, 2005 at 03:13:09PM -0400, Jeremy Katz wrote: > > On Sun, 2005-05-08 at 06:53 -0400, Ignacio Vazquez-Abrams wrote: > > > Here's a prelim patch that handles both build and disttags. Feel free to > > > slice-and-dice as desired. > > > > spot cleaned it up a little bit (moved the common dir stuff to the top > > of Makefile.common so that it would work :-) and I've now applied it. > > Specifying TARGET= should still work if you want, but this can make the > > default case simpler. > > > > Thanks for taking a crack at this > > Does this mean that maintainers can now remove any hard-coded %{dist} and > %{fedora} macros they have in the spec files? Yes. I'd even go so far to say that you must do this. And before anyone flames me, I'm doing it right now (for my packages). ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From gemi at bluewin.ch Mon May 9 20:36:59 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 09 May 2005 22:36:59 +0200 Subject: debuginfo packages Message-ID: <1115671019.2624.0.camel@scriabin.tannenrauch.ch> Wouldn't it be better if the debuginfo packages were in a seperate (sub)repository? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From skvidal at phy.duke.edu Mon May 9 20:38:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 09 May 2005 16:38:38 -0400 Subject: debuginfo packages In-Reply-To: <1115671019.2624.0.camel@scriabin.tannenrauch.ch> References: <1115671019.2624.0.camel@scriabin.tannenrauch.ch> Message-ID: <1115671119.21549.111.camel@cutter> On Mon, 2005-05-09 at 22:36 +0200, G?rard Milmeister wrote: > Wouldn't it be better if the debuginfo packages were in a seperate > (sub)repository? yes, it's a bug in the push script I wrote. I'll correct it tonight. -sv From bugs.michael at gmx.net Mon May 9 20:52:04 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 9 May 2005 22:52:04 +0200 Subject: Extras Builds In-Reply-To: <1115668292.3017.96.camel@localhost.localdomain> References: <1115477983.15593.36.camel@cutter> <1115479482.7124.13.camel@ignacio.ignacio.lan> <1115491264.3302.80.camel@bree.local.net> <1115549596.13384.15.camel@ignacio.ignacio.lan> <1115665989.9762.73.camel@bree.local.net> <20050509192808.GA6704@yoda.jdub.homelinux.org> <1115668292.3017.96.camel@localhost.localdomain> Message-ID: <20050509225204.7b70e5e5.bugs.michael@gmx.net> On Mon, 09 May 2005 14:51:32 -0500, Tom 'spot' Callaway wrote: > On Mon, 2005-05-09 at 14:28 -0500, Josh Boyer wrote: > > On Mon, May 09, 2005 at 03:13:09PM -0400, Jeremy Katz wrote: > > > On Sun, 2005-05-08 at 06:53 -0400, Ignacio Vazquez-Abrams wrote: > > > > Here's a prelim patch that handles both build and disttags. Feel free to > > > > slice-and-dice as desired. > > > > > > spot cleaned it up a little bit (moved the common dir stuff to the top > > > of Makefile.common so that it would work :-) and I've now applied it. > > > Specifying TARGET= should still work if you want, but this can make the > > > default case simpler. > > > > > > Thanks for taking a crack at this > > > > Does this mean that maintainers can now remove any hard-coded %{dist} and > > %{fedora} macros they have in the spec files? > > Yes. I'd even go so far to say that you must do this. And before anyone > flames me, I'm doing it right now (for my packages). Yeah, I flame you for doing it also in the FC3 tree and doing FC3 rebuilds only for this. That is plain silly. Fedora Extras FC3 is not Development where users expect daily updates. If you did it with the next real update, no objections. But to request immediate rebuilds, bah. Everyone else, please treat FC3 more like a stable release and not a playground. From notting at redhat.com Mon May 9 21:08:51 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 9 May 2005 17:08:51 -0400 Subject: packages with broken debuginfo Message-ID: <20050509210851.GA7327@nostromo.devel.redhat.com> The following packages in Fedora Core and Fedora Extras currently appear to have broken debuginfo, in that the debuginfo package has no files. If there is no reason for debuginfo to be valid for the package (the aspell dictionaries come to mind here), you can disable it with: %define debug_package %{nil} in the spec file. Ways to fix include: - making sure apps aren't installed with 'install -s', or linked with 'ld -s' - making sure the package is built with $RPM_OPT_FLAGS Fedora Core packages: --------------------- aspell-af-debuginfo-0.50-2.i386.rpm aspell-br-debuginfo-0.50-2.i386.rpm aspell-ca-debuginfo-0.50-2.i386.rpm aspell-cy-debuginfo-0.50-2.i386.rpm aspell-el-debuginfo-0.50-2.i386.rpm aspell-fo-debuginfo-0.51-2.i386.rpm aspell-ga-debuginfo-0.50-2.i386.rpm aspell-gd-debuginfo-0.50-2.i386.rpm aspell-gl-debuginfo-0.50-2.i386.rpm aspell-hr-debuginfo-0.51-2.i386.rpm aspell-id-debuginfo-0.50.1-2.i386.rpm at-debuginfo-3.1.8-77_FC4.i386.rpm boost-debuginfo-1.32.0-3.i386.rpm busybox-debuginfo-1.00-4.i386.rpm byacc-debuginfo-1.9-29.i386.rpm cpuspeed-debuginfo-1.2.1-1.20.i386.rpm dhcpv6-debuginfo-0.10-13.i386.rpm dosfstools-debuginfo-2.10-3.i386.rpm dump-debuginfo-0.4b40-1.i386.rpm emacspeak-debuginfo-21.0-2.i386.rpm ftp-debuginfo-0.17-25.i386.rpm gnome-mime-data-debuginfo-2.4.2-1.i386.rpm gnome-themes-debuginfo-2.10.1-2.i386.rpm hdparm-debuginfo-5.9-1.i386.rpm iddev-debuginfo-1.9-20.i386.rpm intltool-debuginfo-0.33-2.i386.rpm iptraf-debuginfo-2.7.0-13.i386.rpm ipvsadm-debuginfo-1.24-7.i386.rpm isicom-debuginfo-3.05-18.i386.rpm java-1.4.2-gcj-compat-debuginfo-1.4.2.0-40jpp_18rh.i386.rpm ksh-debuginfo-20050202-1.i386.rpm lsof-debuginfo-4.74-6.i386.rpm man-debuginfo-1.5p-4.i386.rpm mkinitrd-debuginfo-4.2.11-1.i386.rpm mktemp-debuginfo-1.5-23.i386.rpm nfs-utils-debuginfo-1.0.7-6.i386.rpm nmap-debuginfo-3.81-3.i386.rpm openoffice.org-debuginfo-1.9.100-1.i386.rpm passwd-debuginfo-0.69-2.i386.rpm pciutils-debuginfo-2.1.99.test8-8.i386.rpm pkgconfig-debuginfo-0.15.0-6.i386.rpm privoxy-debuginfo-3.0.3-7.i386.rpm procinfo-debuginfo-18-15.i386.rpm procps-debuginfo-3.2.5-4.i386.rpm pwlib-debuginfo-1.8.4-1.i386.rpm rdesktop-debuginfo-1.4.0-2.i386.rpm redhat-lsb-debuginfo-1.3-10.i386.rpm sash-debuginfo-3.7-6.i386.rpm setarch-debuginfo-1.7-2.i386.rpm sg3_utils-debuginfo-1.06-5.i386.rpm slang-debuginfo-1.4.9-17.i386.rpm statserial-debuginfo-1.1-37.i386.rpm symlinks-debuginfo-1.2-24.i386.rpm syslinux-debuginfo-3.07-2.i386.rpm sysstat-debuginfo-5.0.5-9.fc.i386.rpm system-config-boot-debuginfo-0.2.9-1.i386.rpm system-config-netboot-debuginfo-0.1.14-1.i386.rpm tar-debuginfo-1.15.1-5.i386.rpm timidity++-debuginfo-2.13.2-1.i386.rpm utempter-debuginfo-0.5.5-6.i386.rpm vconfig-debuginfo-1.8-7.i386.rpm vlock-debuginfo-1.3-18.i386.rpm ypbind-debuginfo-1.17.2-5.i386.rpm yp-tools-debuginfo-2.8-8.i386.rpm Fedora Extras packages: ----------------------- abicheck-debuginfo-1.2-4.i386.rpm aterm-debuginfo-0.4.2-6.i386.rpm bluefish-debuginfo-1.0-3.i386.rpm chkrootkit-debuginfo-0.45-2.i386.rpm cvsup-debuginfo-16.1-8.h.i386.rpm epydoc-debuginfo-2.1-2.i386.rpm factory-debuginfo-2.0.5-4.i386.rpm fbida-debuginfo-2.03-4.i386.rpm freeze-debuginfo-2.5.0-3.i386.rpm fwbuilder-debuginfo-2.0.6-1.i386.rpm gai-pal-debuginfo-0.7-5.i386.rpm gramps-debuginfo-1.0.10-2.i386.rpm jed-debuginfo-0.99.16-8.i386.rpm john-debuginfo-1.6-3.i386.rpm kile-i18n-debuginfo-1.7-4.i386.rpm kphone-debuginfo-4.1.0-12.i386.rpm libassuan-debuginfo-0.6.9-3.i386.rpm libebml-debuginfo-0.7.3-1.i386.rpm libfac-debuginfo-2.0.5-2.i386.rpm libmatroska-debuginfo-0.7.5-1.i386.rpm libnet10-debuginfo-1.0.2a-6.i386.rpm libtar-debuginfo-1.2.11-4.i386.rpm linux_logo-debuginfo-4.10-1.i386.rpm lua-debuginfo-5.0.2-3.i386.rpm mknbi-debuginfo-1.4.0-3.i386.rpm moodss-debuginfo-17.17-2.i386.rpm nget-debuginfo-0.27.1-2.i386.rpm nmh-debuginfo-1.1-5.fc4.i386.rpm pexpect-debuginfo-0.999-3.i386.rpm plib-debuginfo-1.8.3-6.i386.rpm plib16-debuginfo-1.6.0-2.i386.rpm powermanga-debuginfo-0.79-3.i386.rpm proftpd-debuginfo-1.2.10-3.i386.rpm scribus-debuginfo-1.2.1-4.i386.rpm xdesktopwaves-debuginfo-1.3-2.i386.rpm From dwmw2 at infradead.org Mon May 9 21:10:02 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 09 May 2005 22:10:02 +0100 Subject: packages with broken debuginfo In-Reply-To: <20050509210851.GA7327@nostromo.devel.redhat.com> References: <20050509210851.GA7327@nostromo.devel.redhat.com> Message-ID: <1115673002.12012.423.camel@baythorne.infradead.org> On Mon, 2005-05-09 at 17:08 -0400, Bill Nottingham wrote: > cvsup-debuginfo-16.1-8.h.i386.rpm Ain't gonna happen. Getting Modula-3 to run on PPC was enough pain for me, thank you very much :) -- dwmw2 From davej at redhat.com Mon May 9 22:34:26 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 9 May 2005 18:34:26 -0400 Subject: packages with broken debuginfo In-Reply-To: <20050509210851.GA7327@nostromo.devel.redhat.com> References: <20050509210851.GA7327@nostromo.devel.redhat.com> Message-ID: <20050509223426.GB29206@redhat.com> On Mon, May 09, 2005 at 05:08:51PM -0400, Bill Nottingham wrote: > Ways to fix include: > - making sure apps aren't installed with 'install -s', or > linked with 'ld -s' > - making sure the package is built with $RPM_OPT_FLAGS Removing explicit calls to 'strip' from the Makefile of the program during its %build :-) > cpuspeed-debuginfo-1.2.1-1.20.i386.rpm Fixed. Dave From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 10 08:41:02 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 10 May 2005 10:41:02 +0200 Subject: packages with broken debuginfo In-Reply-To: <20050509210851.GA7327@nostromo.devel.redhat.com> References: <20050509210851.GA7327@nostromo.devel.redhat.com> Message-ID: <20050510104102.0664f622@python2> Bill Nottingham wrote : > Fedora Extras packages: > ----------------------- [...] > libebml-debuginfo-0.7.3-1.i386.rpm > libmatroska-debuginfo-0.7.5-1.i386.rpm > plib-debuginfo-1.8.3-6.i386.rpm > plib16-debuginfo-1.6.0-2.i386.rpm [...] These have in common that they only produce static libraries, no shared. Is it then normal to not have the debug symbols stripped out, or is it because of some problem, like needing to chmod +x the static libs? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.23 1.25 0.70 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 10 09:38:11 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 10 May 2005 11:38:11 +0200 Subject: packages with broken debuginfo In-Reply-To: <20050509210851.GA7327@nostromo.devel.redhat.com> References: <20050509210851.GA7327@nostromo.devel.redhat.com> Message-ID: <20050510113811.73003752@python2> Bill Nottingham wrote : > powermanga-debuginfo-0.79-3.i386.rpm Hmm... it seems like the brp-strip magic doesn't like this package. I can see two specificities : 1) The binary is in /usr/games 2) The binary is set g+s (games) For 1), looking at the brp-strip script, and given that I have other packages with the binary there that get proper debuginfo, that's not it. For 2), looking at the "find" args from brp-strip, I don't see how that can be a problem either. I'm confused :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 1.08 1.02 0.89 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 10 13:03:30 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 10 May 2005 15:03:30 +0200 Subject: Extras build system problem Message-ID: <20050510150330.55c59311@python2> Hi, I just got a build failure on ppc for a package : Installing group 'minimal' ....error: /usr/sbin/mach-helper yum -- installroot /var/lib/mach/roots/fedora-development-ppc-core -c /var/lib/ mach/states/fedora-development-ppc-core/yum.conf groupinstall build- minimal failed. Setting up Group Process Setting up repositories ^Mcore 100% |=========================| 1.1 kB 00:00 ^Mextras 100% |=========================| 951 B 00:00 ^Mlocal 100% |=========================| 951 B 00:00 Cannot open/read repomd.xml file for repository: groups failure: repodata/repomd.xml from groups: [Errno 256] No more mirrors to try. ERROR: Could not get build-minimal ! Seems like the ppc build machine can't reach the groups files (which were put on a webserver by seth IIRC). Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.30 0.79 0.81 From pnasrat at redhat.com Tue May 10 13:18:55 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 10 May 2005 09:18:55 -0400 Subject: Extras build system problem In-Reply-To: <20050510150330.55c59311@python2> References: <20050510150330.55c59311@python2> Message-ID: <1115731135.3546.50.camel@enki.eridu> On Tue, 2005-05-10 at 15:03 +0200, Matthias Saou wrote: > Hi, > > I just got a build failure on ppc for a package : > Seems like the ppc build machine can't reach the groups files (which were > put on a webserver by seth IIRC). The box hosting linux.duke.edu was down earlier it seems to be back up - please retry. Paul From skvidal at phy.duke.edu Tue May 10 13:21:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 May 2005 09:21:03 -0400 Subject: Extras build system problem In-Reply-To: <1115731135.3546.50.camel@enki.eridu> References: <20050510150330.55c59311@python2> <1115731135.3546.50.camel@enki.eridu> Message-ID: <1115731263.10234.3.camel@cutter> On Tue, 2005-05-10 at 09:18 -0400, Paul Nasrat wrote: > On Tue, 2005-05-10 at 15:03 +0200, Matthias Saou wrote: > > Hi, > > > > I just got a build failure on ppc for a package : > > > Seems like the ppc build machine can't reach the groups files (which were > > put on a webserver by seth IIRC). > > The box hosting linux.duke.edu was down earlier it seems to be back up - > please retry. > Yep, The machine died, I just restarted it and I moved that location in the mach entries. It now points to fedoraproject.org/buildgroup/ -sv From pnasrat at redhat.com Tue May 10 13:33:09 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Tue, 10 May 2005 09:33:09 -0400 Subject: Extras build system problem In-Reply-To: <1115731263.10234.3.camel@cutter> References: <20050510150330.55c59311@python2> <1115731135.3546.50.camel@enki.eridu> <1115731263.10234.3.camel@cutter> Message-ID: <1115731990.3546.52.camel@enki.eridu> On Tue, 2005-05-10 at 09:21 -0400, seth vidal wrote: > The machine died, I just restarted it and I moved that location in the > mach entries. It now points to fedoraproject.org/buildgroup/ http://fedoraproject.org/buildgroups/ Paul From skvidal at phy.duke.edu Tue May 10 13:34:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 10 May 2005 09:34:13 -0400 Subject: Extras build system problem In-Reply-To: <1115731990.3546.52.camel@enki.eridu> References: <20050510150330.55c59311@python2> <1115731135.3546.50.camel@enki.eridu> <1115731263.10234.3.camel@cutter> <1115731990.3546.52.camel@enki.eridu> Message-ID: <1115732053.10234.15.camel@cutter> On Tue, 2005-05-10 at 09:33 -0400, Paul Nasrat wrote: > On Tue, 2005-05-10 at 09:21 -0400, seth vidal wrote: > > > The machine died, I just restarted it and I moved that location in the > > mach entries. It now points to fedoraproject.org/buildgroup/ > > http://fedoraproject.org/buildgroups/ > yah, sorry, typo. -sv From kzak at redhat.com Tue May 10 15:05:55 2005 From: kzak at redhat.com (Karel Zak) Date: Tue, 10 May 2005 17:05:55 +0200 Subject: packages with broken debuginfo In-Reply-To: <20050509210851.GA7327@nostromo.devel.redhat.com> References: <20050509210851.GA7327@nostromo.devel.redhat.com> Message-ID: <1115737555.23635.87.camel@petra> On Mon, 2005-05-09 at 17:08 -0400, Bill Nottingham wrote: > lsof-debuginfo-4.74-6.i386.rpm > procinfo-debuginfo-18-15.i386.rpm > procps-debuginfo-3.2.5-4.i386.rpm > vlock-debuginfo-1.3-18.i386.rpm Fixed. Karel -- Karel Zak From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue May 10 15:59:48 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 10 May 2005 17:59:48 +0200 Subject: Extras build system problem In-Reply-To: <1115732053.10234.15.camel@cutter> References: <20050510150330.55c59311@python2> <1115731135.3546.50.camel@enki.eridu> <1115731263.10234.3.camel@cutter> <1115731990.3546.52.camel@enki.eridu> <1115732053.10234.15.camel@cutter> Message-ID: <20050510175948.66f20b98@python2> seth vidal wrote : > On Tue, 2005-05-10 at 09:33 -0400, Paul Nasrat wrote: > > On Tue, 2005-05-10 at 09:21 -0400, seth vidal wrote: > > > > > The machine died, I just restarted it and I moved that location in the > > > mach entries. It now points to fedoraproject.org/buildgroup/ > > > > http://fedoraproject.org/buildgroups/ > > > > yah, sorry, typo. Now, I just got this in the ppc log : "Build process terminated by timeout" :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.20_FC3 Load : 0.81 0.69 0.63 From notting at redhat.com Tue May 10 16:05:42 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 10 May 2005 12:05:42 -0400 Subject: packages with broken debuginfo In-Reply-To: <20050510104102.0664f622@python2> References: <20050509210851.GA7327@nostromo.devel.redhat.com> <20050510104102.0664f622@python2> Message-ID: <20050510160542.GB3820@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > Bill Nottingham wrote : > > > Fedora Extras packages: > > ----------------------- > [...] > > libebml-debuginfo-0.7.3-1.i386.rpm > > libmatroska-debuginfo-0.7.5-1.i386.rpm > > plib-debuginfo-1.8.3-6.i386.rpm > > plib16-debuginfo-1.6.0-2.i386.rpm > [...] > > These have in common that they only produce static libraries, no shared. > Is it then normal to not have the debug symbols stripped out, or is it > because of some problem, like needing to chmod +x the static libs? As I understand, the debug symbols are stripped out, but no debuginfo is created. Hm, this could be a bug with how debuginfo packages are generated. Bill From otaylor at redhat.com Tue May 10 17:17:15 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 10 May 2005 13:17:15 -0400 Subject: packages with broken debuginfo In-Reply-To: <20050510160542.GB3820@nostromo.devel.redhat.com> References: <20050509210851.GA7327@nostromo.devel.redhat.com> <20050510104102.0664f622@python2> <20050510160542.GB3820@nostromo.devel.redhat.com> Message-ID: <1115745435.7052.8.camel@localhost.localdomain> On Tue, 2005-05-10 at 12:05 -0400, Bill Nottingham wrote: > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > Bill Nottingham wrote : > > > > > Fedora Extras packages: > > > ----------------------- > > [...] > > > libebml-debuginfo-0.7.3-1.i386.rpm > > > libmatroska-debuginfo-0.7.5-1.i386.rpm > > > plib-debuginfo-1.8.3-6.i386.rpm > > > plib16-debuginfo-1.6.0-2.i386.rpm > > [...] > > > > These have in common that they only produce static libraries, no shared. > > Is it then normal to not have the debug symbols stripped out, or is it > > because of some problem, like needing to chmod +x the static libs? > > As I understand, the debug symbols are stripped out, but no > debuginfo is created. Hm, this could be a bug with how debuginfo > packages are generated. It seems to me that the way this *should* work is: - The main libs package contains the debug symbols, not stripped (separate debug symbols aren't going to work for a static library, as far as I can see.) - The debuginfo package contains the sources, as per-normal Of course, that's probably a lot of work. Simply running strip -g on the libraries and turning off the debuginfo packages is going to be a lot simpler, though the resulting linked executables won't be debuggable. Really, of course, the answer is to avoid static libraries. This is just the tip of the iceberg for problems with static libraries. They don't work across libc version changes, for another example. Regards, Owen -------------- 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 roland at redhat.com Tue May 10 20:43:50 2005 From: roland at redhat.com (Roland McGrath) Date: Tue, 10 May 2005 13:43:50 -0700 Subject: packages with broken debuginfo In-Reply-To: Owen Taylor's message of Tuesday, 10 May 2005 13:17:15 -0400 <1115745435.7052.8.camel@localhost.localdomain> Message-ID: <200505102043.j4AKhoEL002707@magilla.sf.frob.com> > It seems to me that the way this *should* work is: > > - The main libs package contains the debug symbols, not stripped > (separate debug symbols aren't going to work for a static library, > as far as I can see.) They definitely cannot work as things stand. > - The debuginfo package contains the sources, as per-normal > > Of course, that's probably a lot of work. Not necessarily. There's a of magic that's done to create debuginfo packages beyond just using eu-strip -g -f. There is also /usr/lib/rpm/debugedit, which normalizes the file names in the debugging information to /usr/src/debug names, and along the way collects the list of source files that need to go in the debuginfo rpm. debugedit could be pretty easily extended to handle .a libraries, and run on the unstripped libfoo.a to fix up their source file names and collect the list. > Really, of course, the answer is to avoid static libraries. This is > just the tip of the iceberg for problems with static libraries. > They don't work across libc version changes, for another example. Indeed they are in general not really supported. But on rare occasions they are unavoidable, and it would be ideal to have nice debuginfo for programs that are statically linked against installed libraries. From varekova at redhat.com Wed May 11 08:08:18 2005 From: varekova at redhat.com (Ivana Varekova) Date: Wed, 11 May 2005 10:08:18 +0200 Subject: packages with broken debuginfo In-Reply-To: <20050509210851.GA7327@nostromo.devel.redhat.com> References: <20050509210851.GA7327@nostromo.devel.redhat.com> Message-ID: <1115798898.3697.3.camel@cytherea.redhat.usu> > aspell-af-debuginfo-0.50-2.i386.rpm > aspell-br-debuginfo-0.50-2.i386.rpm > aspell-ca-debuginfo-0.50-2.i386.rpm > aspell-cy-debuginfo-0.50-2.i386.rpm > aspell-el-debuginfo-0.50-2.i386.rpm > aspell-fo-debuginfo-0.51-2.i386.rpm > aspell-ga-debuginfo-0.50-2.i386.rpm > aspell-gd-debuginfo-0.50-2.i386.rpm > aspell-gl-debuginfo-0.50-2.i386.rpm > aspell-hr-debuginfo-0.51-2.i386.rpm > aspell-id-debuginfo-0.50.1-2.i386.rpm > busybox-debuginfo-1.00-4.i386.rpm > man-debuginfo-1.5p-4.i386.rpm > sysstat-debuginfo-5.0.5-9.fc.i386.rpm Fixed. Ivana Varekova From notting at redhat.com Thu May 12 03:31:50 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 11 May 2005 23:31:50 -0400 Subject: mismatch of versions between arches Message-ID: <20050512033150.GA2261@nostromo.devel.redhat.com> The following packages in Fedora Extras don't have the same version across i386/x86_64/ppc in the built repostory, and don't have an ExcludeArch/ExclusiveArch that explains it in brief checking. Please get these rectified; having the repository consistent is A Good Thing. abiword advancecomp aiksaurus allegro amarok amaya apmud aqhbci-qt-tools arc audacity awstats bash-completion bittorrent blender bluefish bochs brightside camstream celestia centericq clearlooks cone cook csmash dhcp-forwarder dietlibc directfb dkms doctorj dosbox elmo factory fbida fftw fontforge freedroidrpg fslint fwbuilder gconfmm20 gkrellm-hddtemp global gmime gnome-applet-netmon gnome-blog gnome-common gnome-theme-clearlooks gnome-themes-extras gnupg2 gpa gpgme graphviz grisbi gstreamer-python GtkAda gtranslator gurlchecker gwenview hercules Hermes htmltmpl hunt icu id3-py inkscape Inventor ip-sentinel jabberd jikes jlint john jpgraph kickpim kid3 kile kile-i18n kover kphone ksensors ktrack lablgl lablgtk ladspa lcms leafnode lft lib3ds libcddb libdaemon libebml libfac libglademm20 libgnomecanvasmm20 libgnomemm20 libgnomeuimm20 libid3tag libkexif libkipi libksba libmatroska libnet10 liboil libosip2 librsync libsamplerate libshout libsidplay libsigsegv libsndfile libtar libtasn1 libuninameslist libvisual libxfce4mcs libxfcegui4 libxml++ libzvt lighttpd lincvs linux_logo lmarbles lua lyx lzo lzop Macaulay2 mail-notification mantis mathml-fonts meld metakit mhash mhonarc milter-greylist mpc nabi netcdf netdiag nethack-falconseye netmask neverball neXtaw nget nomarch ocaml oidentd openal opencdk openct opensc openslp ots p0f pam_mysql parchive pcsc-lite pcsc-perl perl-Class-MethodMaker perl-Convert-TNEF perl-IO-Zlib perl-MIME-Types perl-Net-SCP perl-PAR-Dist perl-Pod-Coverage perl-Razor-Agent perl-Test-Builder-Tester perl-Test-Exception perl-Test-Manifest perl-Test-Pod perl-Test-Pod-Coverage perl-XML-RSS pgadmin3 php-pecl-sqlite plib plib16 plone pop-before-smtp portaudio powermanga proftpd proj prozilla psi pth pybliographer python-amara python-dialog python-docutils python-elementtree python-goopy python-HTMLgen python-imaging python-numeric python-protocols python-psycopg python-reportlab python-simpletal python-tpg pyzor qa-assistant qca qcad qca-tls qhull qiv qtparted rdiff-backup repoml revelation rkhunter rpmDirectoryCheck rpmproc rrdtool rxvt sabayon scons scorched3d screem scribus scribus-templates seahorse shorewall sirius skencil sodipodi soundtracker source-highlight starfighter stow straw supertux swatch sylpheed synce system-switch-im t1lib t1utils tdl tetex-arabtex tetex-armtex tetex-beamer tetex-bytefield tetex-eurofont tetex-font-cm-lgc tetex-font-kerkis tetex-font-tipa tetex-lgrind tetex-pgf tetex-unicode tetex-xcolor TeXmacs themes-backgrounds-gnome thttpd tidy tin tkcvs tktable tla torcs torcs-data tpb treecc ttf2pt1 tuxpaint tuxtype2 ucl ufraw unison unrtf upx uqm-content viruskiller vnc-ltsp-config vnstat vpnc w3c-markup-validator wbxml2 wesnoth wv wxPythonGTK2 xbindkeys xca xcin xdesktopwaves xfce4-appfinder xfce4-iconbox xfce4-icon-theme xfce4-panel xfce4-systray xfce4-toys xfce4-trigger-launcher xfce-mcs-manager xfce-mcs-plugins xfce-utils xfdesktop xffm xforms xfprint xlhtml xmlindent xmms xmms-acme xmms-cdread xmms-lirc xmms-modplug xmms-sid xosd xplanet xtide xvattr yasm zziplib From bugs.michael at gmx.net Thu May 12 05:36:40 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 07:36:40 +0200 Subject: mismatch of versions between arches In-Reply-To: <20050512033150.GA2261@nostromo.devel.redhat.com> References: <20050512033150.GA2261@nostromo.devel.redhat.com> Message-ID: <20050512073640.7db9aace.bugs.michael@gmx.net> On Wed, 11 May 2005 23:31:50 -0400, Bill Nottingham wrote: > The following packages in Fedora Extras don't have the same > version across i386/x86_64/ppc in the built repostory, and > don't have an ExcludeArch/ExclusiveArch that explains it in > brief checking. The explanation is a different one. Fedora pre-Extras started with i386/x86_64 builds only and published whatever did built on i386. No ppc builds were done. Only later build failures on one arch have started to block an entire release. And no mass-rebuild for ppc was done either when a ppc build box was introduced. -- Fedora Core release 3.91 (Pre-FC4) - Linux 2.6.11-1.1290_FC4 loadavg: 1.08 1.05 0.92 From byte at aeon.com.my Thu May 12 06:32:06 2005 From: byte at aeon.com.my (Colin Charles) Date: Thu, 12 May 2005 16:32:06 +1000 Subject: mismatch of versions between arches In-Reply-To: <20050512073640.7db9aace.bugs.michael@gmx.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> Message-ID: <1115879526.4525.67.camel@arena.soho.bytebot.net> On Thu, 2005-05-12 at 07:36 +0200, Michael Schwendt wrote: > The explanation is a different one. Fedora pre-Extras started with > i386/x86_64 builds only and published whatever did built on i386. No > ppc > builds were done. Only later build failures on one arch have started > to > block an entire release. Wrong; they were being built here at home right up until pre-FC4t2 for ppc (when Seth got a build box, and I stopped) > And no mass-rebuild for ppc was done either when a ppc build box was > introduced. I reckon as FC-4 becomes near, we need a mass rebuild on all arch's, one way or another How about the date get set to start around 26th May? This gives us relatively enough time to rebuild, and get things fixed before 6th June. -- Colin Charles, http://www.bytebot.net/ From bugs.michael at gmx.net Thu May 12 06:55:16 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 08:55:16 +0200 Subject: mismatch of versions between arches In-Reply-To: <1115879526.4525.67.camel@arena.soho.bytebot.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> Message-ID: <20050512085516.2c37c93e.bugs.michael@gmx.net> On Thu, 12 May 2005 16:32:06 +1000, Colin Charles wrote: > On Thu, 2005-05-12 at 07:36 +0200, Michael Schwendt wrote: > > The explanation is a different one. Fedora pre-Extras started with > > i386/x86_64 builds only and published whatever did built on i386. No > > ppc > > builds were done. Only later build failures on one arch have started > > to > > block an entire release. > > Wrong; they were being built here at home right up until pre-FC4t2 for > ppc (when Seth got a build box, and I stopped) Wrong or right, doesn't matter at all. There's a huge discrepancy between what packages we have on each of the architectures. And really nobody else has the overview of what was built for ppc and what was not. > > And no mass-rebuild for ppc was done either when a ppc build box was > > introduced. > > I reckon as FC-4 becomes near, we need a mass rebuild on all arch's, one > way or another Or just a rebuild of packages, which have not been built with gcc4 yet. > How about the date get set to start around 26th May? This gives us > relatively enough time to rebuild, and get things fixed before 6th June. Fedora Extras FC4 target bugs https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=157183 (would be great if the dep tree listed the architecture, too, btw) From fedora at leemhuis.info Thu May 12 07:08:45 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 May 2005 09:08:45 +0200 Subject: mismatch of versions between arches In-Reply-To: <20050512085516.2c37c93e.bugs.michael@gmx.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> Message-ID: <1115881725.14299.15.camel@thl.ct.heise.de> Am Donnerstag, den 12.05.2005, 08:55 +0200 schrieb Michael Schwendt: > On Thu, 12 May 2005 16:32:06 +1000, Colin Charles wrote: > > On Thu, 2005-05-12 at 07:36 +0200, Michael Schwendt wrote: > > How about the date get set to start around 26th May? This gives us > > relatively enough time to rebuild, and get things fixed before 6th June. > Fedora Extras FC4 target bugs > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=157183 > > (would be great if the dep tree listed the architecture, too, btw) We could create more tracker bugs: "FC4 x86_64 tracker" "FC4 ppc tracker"; Those could be dep bugs for the "FC4 general tracker" bug. You would see the arch deps in that dependecytree then. Similar like Bug 155836 in the dep-tree of https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=136450 I was planing something like that anyway to track x86_64 bugs better. Just my 2 cent -- Thorsten Leemhuis From byte at aeon.com.my Thu May 12 07:19:14 2005 From: byte at aeon.com.my (Colin Charles) Date: Thu, 12 May 2005 17:19:14 +1000 Subject: mismatch of versions between arches In-Reply-To: <20050512085516.2c37c93e.bugs.michael@gmx.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> Message-ID: <1115882355.4525.73.camel@arena.soho.bytebot.net> On Thu, 2005-05-12 at 08:55 +0200, Michael Schwendt wrote: > > > The explanation is a different one. Fedora pre-Extras started with > > > i386/x86_64 builds only and published whatever did built on i386. No > > > ppc > > > builds were done. Only later build failures on one arch have started > > > to > > > block an entire release. > > > > Wrong; they were being built here at home right up until pre-FC4t2 for > > ppc (when Seth got a build box, and I stopped) > > Wrong or right, doesn't matter at all. There's a huge discrepancy between > what packages we have on each of the architectures. And really nobody else > has the overview of what was built for ppc and what was not. repoview had the generated magic, fwiw. http://fedoraproject.org/extras/development/ppc/repodata/ And I did post failed logs, and alerted extras-list > > > And no mass-rebuild for ppc was done either when a ppc build box was > > > introduced. > > > > I reckon as FC-4 becomes near, we need a mass rebuild on all arch's, one > > way or another > > Or just a rebuild of packages, which have not been built with gcc4 yet. Do these still exist on x86, as well? > > How about the date get set to start around 26th May? This gives us > > relatively enough time to rebuild, and get things fixed before 6th June. > > Fedora Extras FC4 target bugs > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=157183 Thanks > (would be great if the dep tree listed the architecture, too, btw) And thanks for adding to the the fedora-ppc tracker as well (which you've done a great job of doing when its arch specific) -- Colin Charles, http://www.bytebot.net/ From bugs.michael at gmx.net Thu May 12 07:28:25 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 12 May 2005 09:28:25 +0200 Subject: mismatch of versions between arches In-Reply-To: <1115882355.4525.73.camel@arena.soho.bytebot.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> <1115882355.4525.73.camel@arena.soho.bytebot.net> Message-ID: <20050512092825.12e74fb3.bugs.michael@gmx.net> On Thu, 12 May 2005 17:19:14 +1000, Colin Charles wrote: > And I did post failed logs, and alerted extras-list "If it's not in bugzilla, it's not a bug." That applies to Fedora Extras now, too, the more we scale. > > > > And no mass-rebuild for ppc was done either when a ppc build box was > > > > introduced. > > > > > > I reckon as FC-4 becomes near, we need a mass rebuild on all arch's, one > > > way or another > > > > Or just a rebuild of packages, which have not been built with gcc4 yet. > > Do these still exist on x86, as well? Almost certainly, because the Extras Development repository was filled with FC3 builds, and that way ABI problems creep in (like the crashes seen with Inkscape). From dwmw2 at infradead.org Thu May 12 08:23:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 May 2005 09:23:17 +0100 Subject: mismatch of versions between arches In-Reply-To: <20050512085516.2c37c93e.bugs.michael@gmx.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> Message-ID: <1115886197.12012.445.camel@baythorne.infradead.org> On Thu, 2005-05-12 at 08:55 +0200, Michael Schwendt wrote: > Fedora Extras FC4 target bugs > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=157183 > > (would be great if the dep tree listed the architecture, too, btw) That would be useful if the architecture is relevant to the bug, or if the package maintainer wants to attract the attention of an architecture expert for assistance. In either of those cases, the package maintainer should be encouraged to change the Summary field of the bug report accordingly. Specifying the _package_ in the dependency tree would be a more useful thing to do unconditionally than specifying the architecture :) -- dwmw2 From fedora at leemhuis.info Thu May 12 09:08:49 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 May 2005 11:08:49 +0200 Subject: mismatch of versions between arches In-Reply-To: <20050512092825.12e74fb3.bugs.michael@gmx.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> <1115882355.4525.73.camel@arena.soho.bytebot.net> <20050512092825.12e74fb3.bugs.michael@gmx.net> Message-ID: <1115888929.14299.40.camel@thl.ct.heise.de> Am Donnerstag, den 12.05.2005, 09:28 +0200 schrieb Michael Schwendt: > On Thu, 12 May 2005 17:19:14 +1000, Colin Charles wrote: > > > > I reckon as FC-4 becomes near, we need a mass rebuild on all arch's, one > > > > way or another > > > > > > Or just a rebuild of packages, which have not been built with gcc4 yet. > > > > Do these still exist on x86, as well? > > Almost certainly, because the Extras Development repository was filled > with FC3 builds, and that way ABI problems creep in (like the crashes seen > with Inkscape). Another minor argument for a mass rebuild and a note to all: It seems that during the initial rebuild some packages for x86_64 were not build, but the information never made it to the wiki or bugzilla. Just look at: http://download.fedora.redhat.com/pub/fedora/linux/extras/development/x86_64/ There are a lot of old FC3 packages (those older than around Apr 11, see http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/extras/development/x86_64/?C=M;O=A for another view) -- a lot more than in the i386-devel-tree Just a quick look did turn up a lot of packages like xforms, tidy, tuxpaint, celestia and probably a lot more. Their FC3-versions are still in devel for x86_64 because the inital devel-build for x86_64 failed. But it seems the i386 version were build on the initial devel rebuild... Normally those failed x86_64 builds should have appeared on Extras/FC4RebuildFailures in the Wiki and later in Bugzilla, but there were only three packages on that list for x86_64 iirc. Not the ones mentioned above. I'll try to look at this next week to fix it before FC4... CU thl From wtogami at redhat.com Thu May 12 09:10:42 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 11 May 2005 23:10:42 -1000 Subject: mismatch of versions between arches In-Reply-To: <1115888929.14299.40.camel@thl.ct.heise.de> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> <1115882355.4525.73.camel@arena.soho.bytebot.net> <20050512092825.12e74fb3.bugs.michael@gmx.net> <1115888929.14299.40.camel@thl.ct.heise.de> Message-ID: <42831D92.7020201@redhat.com> Another reason: gcc4 went through many revisions during FC4 cycle, so packages should be rebuilt to know about possible new problems sooner than later. Warren Togami wtogami at redhat.com From mharris at www.linux.org.uk Thu May 12 10:20:37 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 12 May 2005 06:20:37 -0400 Subject: mismatch of versions between arches In-Reply-To: <20050512033150.GA2261@nostromo.devel.redhat.com> References: <20050512033150.GA2261@nostromo.devel.redhat.com> Message-ID: <42832DF5.8060102@www.linux.org.uk> Bill Nottingham wrote: > The following packages in Fedora Extras don't have the same > version across i386/x86_64/ppc in the built repostory, and > don't have an ExcludeArch/ExclusiveArch that explains it in > brief checking. > > Please get these rectified; having the repository consistent > is A Good Thing. [SNIP] Does Fedora-Extras buildsystem infrastructure build only on one arch at a time, or does it build on all supported arches simultaneously and kill builds on all arches if any one of them should fail? While it's annoying to have one arch kill all of them, it has proven to be a very useful and successful solution for Red Hat internally as far as product consistency is concerned. If Extras doesn't already do this, I'd recommend it for future. From gdk at redhat.com Thu May 12 12:25:57 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Thu, 12 May 2005 08:25:57 -0400 (EDT) Subject: mismatch of versions between arches In-Reply-To: <1115881725.14299.15.camel@thl.ct.heise.de> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> <1115881725.14299.15.camel@thl.ct.heise.de> Message-ID: +1 Tracker bugs are good in so many ways. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ On Thu, 12 May 2005, Thorsten Leemhuis wrote: > Am Donnerstag, den 12.05.2005, 08:55 +0200 schrieb Michael Schwendt: > > On Thu, 12 May 2005 16:32:06 +1000, Colin Charles wrote: > > > On Thu, 2005-05-12 at 07:36 +0200, Michael Schwendt wrote: > > > How about the date get set to start around 26th May? This gives us > > > relatively enough time to rebuild, and get things fixed before 6th June. > > Fedora Extras FC4 target bugs > > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=157183 > > > > (would be great if the dep tree listed the architecture, too, btw) > > We could create more tracker bugs: "FC4 x86_64 tracker" "FC4 ppc > tracker"; Those could be dep bugs for the "FC4 general tracker" bug. You > would see the arch deps in that dependecytree then. > > Similar like Bug 155836 in the dep-tree of > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=136450 > > I was planing something like that anyway to track x86_64 bugs better. > > Just my 2 cent > > -- > Thorsten Leemhuis > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From skvidal at phy.duke.edu Thu May 12 12:34:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 08:34:21 -0400 Subject: mismatch of versions between arches In-Reply-To: <42832DF5.8060102@www.linux.org.uk> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <42832DF5.8060102@www.linux.org.uk> Message-ID: <1115901261.4604.34.camel@cutter> On Thu, 2005-05-12 at 06:20 -0400, Mike A. Harris wrote: > Bill Nottingham wrote: > > The following packages in Fedora Extras don't have the same > > version across i386/x86_64/ppc in the built repostory, and > > don't have an ExcludeArch/ExclusiveArch that explains it in > > brief checking. > > > > Please get these rectified; having the repository consistent > > is A Good Thing. > [SNIP] > > Does Fedora-Extras buildsystem infrastructure build only on > one arch at a time, or does it build on all supported arches > simultaneously and kill builds on all arches if any one of > them should fail? the latter. -sv From shahms at shahms.com Thu May 12 14:36:30 2005 From: shahms at shahms.com (Shahms King) Date: Thu, 12 May 2005 07:36:30 -0700 Subject: ExclusiveArch packages in wrong arch Message-ID: <428369EE.1030009@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 When initially built the "python-psyco" package didn't have the proper ExclusiveArch and so it was built for x86_64 and ppc. I fixed that, but the old builds persist in the repositories for these architectures; how would one go about getting them removed? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCg2nt/qs2NkWy11sRAkZ6AJ9ERV9BSYY4rQ/BvK/AEMEEWkxEJgCfXXxA JnqHWyOQ4+XhNMNN6pS4W54= =e4EW -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Thu May 12 14:38:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 12 May 2005 10:38:14 -0400 Subject: ExclusiveArch packages in wrong arch In-Reply-To: <428369EE.1030009@shahms.com> References: <428369EE.1030009@shahms.com> Message-ID: <1115908694.4604.44.camel@cutter> On Thu, 2005-05-12 at 07:36 -0700, Shahms King wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > When initially built the "python-psyco" package didn't have the proper > ExclusiveArch and so it was built for x86_64 and ppc. I fixed that, but > the old builds persist in the repositories for these architectures; how > would one go about getting them removed? > put it on the wiki status page for removal requests. -sv From jpo at di.uminho.pt Thu May 12 14:47:51 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 12 May 2005 15:47:51 +0100 Subject: mismatch of versions between arches (FC4 core pcakage) In-Reply-To: <20050512033150.GA2261@nostromo.devel.redhat.com> References: <20050512033150.GA2261@nostromo.devel.redhat.com> Message-ID: <42836C97.2080408@di.uminho.pt> Bill Nottingham wrote: > The following packages in Fedora Extras don't have the same > version across i386/x86_64/ppc in the built repostory, and > don't have an ExcludeArch/ExclusiveArch that explains it in > brief checking. > > Please get these rectified; having the repository consistent > is A Good Thing. > > ... > perl-IO-Zlib > ... Please remove perl-IO-Zlib from the development area in the mirrors. It is now a FC4 core package. jpo PS - Someone should also check the python packages in this list (one or more may also be FC4 core packages. e.g.:python-elementtree) -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Thu May 12 17:22:56 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 12 May 2005 20:22:56 +0300 Subject: mismatch of versions between arches (FC4 core pcakage) In-Reply-To: <42836C97.2080408@di.uminho.pt> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <42836C97.2080408@di.uminho.pt> Message-ID: <1115918577.14907.14.camel@bobcat.mine.nu> On Thu, 2005-05-12 at 15:47 +0100, Jos? Pedro Oliveira wrote: > Please remove perl-IO-Zlib from the development area in the > mirrors. It is now a FC4 core package. http://fedoraproject.org/wiki/Extras_2fFC4Status From fedora at leemhuis.info Thu May 12 17:28:59 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 May 2005 19:28:59 +0200 Subject: FC4 Target tracker x86_64 (Was: Re: mismatch of versions between arches) In-Reply-To: References: <20050512033150.GA2261@nostromo.devel.redhat.com> <20050512073640.7db9aace.bugs.michael@gmx.net> <1115879526.4525.67.camel@arena.soho.bytebot.net> <20050512085516.2c37c93e.bugs.michael@gmx.net> <1115881725.14299.15.camel@thl.ct.heise.de> Message-ID: <1115918939.5451.5.camel@notebook.thl.home> Am Donnerstag, den 12.05.2005, 08:25 -0400 schrieb Greg DeKoenigsberg: > +1 > > Tracker bugs are good in so many ways. x86_64: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157553 > On Thu, 12 May 2005, Thorsten Leemhuis wrote: > > > Am Donnerstag, den 12.05.2005, 08:55 +0200 schrieb Michael Schwendt: > > > On Thu, 12 May 2005 16:32:06 +1000, Colin Charles wrote: > > > > On Thu, 2005-05-12 at 07:36 +0200, Michael Schwendt wrote: > > > > How about the date get set to start around 26th May? This gives us > > > > relatively enough time to rebuild, and get things fixed before 6th June. > > > Fedora Extras FC4 target bugs > > > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=157183 > > > > > > (would be great if the dep tree listed the architecture, too, btw) > > > > We could create more tracker bugs: "FC4 x86_64 tracker" "FC4 ppc > > tracker"; Those could be dep bugs for the "FC4 general tracker" bug. You > > would see the arch deps in that dependecytree then. > > > > Similar like Bug 155836 in the dep-tree of > > https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=136450 > > > > I was planing something like that anyway to track x86_64 bugs better. > > > > Just my 2 cent > > > > -- > > Thorsten Leemhuis > > > > -- > > 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 > -- Thorsten Leemhuis From ville.skytta at iki.fi Thu May 12 21:42:01 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 13 May 2005 00:42:01 +0300 Subject: mismatch of versions between arches In-Reply-To: <20050512033150.GA2261@nostromo.devel.redhat.com> References: <20050512033150.GA2261@nostromo.devel.redhat.com> Message-ID: <1115934121.14907.20.camel@bobcat.mine.nu> On Wed, 2005-05-11 at 23:31 -0400, Bill Nottingham wrote: > The following packages in Fedora Extras don't have the same > version across i386/x86_64/ppc in the built repostory, and > don't have an ExcludeArch/ExclusiveArch that explains it in > brief checking. noarch packages that can be copied from i386 to ppc/x86_64 listed at http://fedoraproject.org/wiki/Extras_2fFC4Status Note: I haven't checked the dependencies thoroughly. From jkeating at j2solutions.net Thu May 12 22:37:39 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 12 May 2005 15:37:39 -0700 Subject: Preventing prelink from touching files during build Message-ID: <1115937459.11675.177.camel@jkeating2.hq.pogolinux.com> I'm building some packages that I need prelink to NOT touch wile building them (FC3 host). What can I put in my spec to prevent prelink from making the files break? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Thu May 12 23:31:06 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 12 May 2005 16:31:06 -0700 Subject: Preventing prelink from touching files during build In-Reply-To: <1115937459.11675.177.camel@jkeating2.hq.pogolinux.com> References: <1115937459.11675.177.camel@jkeating2.hq.pogolinux.com> Message-ID: <1115940666.11675.180.camel@jkeating2.hq.pogolinux.com> On Thu, 2005-05-12 at 15:37 -0700, Jesse Keating wrote: > I'm building some packages that I need prelink to NOT touch wile > building them (FC3 host). What can I put in my spec to prevent > prelink > from making the files break? Hrm, ends up not being prelink, I've removed it from the build box. However my file keeps getting thwacked in a way that leads it to no longer be executable. On the same system I can run the install command I have listed in my spec and the file works, so it has to be something in rpmbuild's processing of the files that makes it not work. Has anybody ran into this that could help out? It isn't prelink, it isn't debug stuff, I'm running out of ideas. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From pmatilai at welho.com Fri May 13 06:47:31 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 13 May 2005 09:47:31 +0300 (EEST) Subject: Preventing prelink from touching files during build In-Reply-To: <1115940666.11675.180.camel@jkeating2.hq.pogolinux.com> References: <1115937459.11675.177.camel@jkeating2.hq.pogolinux.com> <1115940666.11675.180.camel@jkeating2.hq.pogolinux.com> Message-ID: On Thu, 12 May 2005, Jesse Keating wrote: > On Thu, 2005-05-12 at 15:37 -0700, Jesse Keating wrote: >> I'm building some packages that I need prelink to NOT touch wile >> building them (FC3 host). What can I put in my spec to prevent >> prelink >> from making the files break? > > Hrm, ends up not being prelink, I've removed it from the build box. > However my file keeps getting thwacked in a way that leads it to no > longer be executable. > > On the same system I can run the install command I have listed in my > spec and the file works, so it has to be something in rpmbuild's > processing of the files that makes it not work. Has anybody ran into > this that could help out? It isn't prelink, it isn't debug stuff, I'm > running out of ideas. Stripping maybe? I know it does break some commercial software I've repackaged, adding '%define __spec_install_post :' to spec helped. - Panu - From jkeating at j2solutions.net Fri May 13 07:12:20 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 13 May 2005 00:12:20 -0700 Subject: Preventing prelink from touching files during build In-Reply-To: References: <1115937459.11675.177.camel@jkeating2.hq.pogolinux.com> <1115940666.11675.180.camel@jkeating2.hq.pogolinux.com> Message-ID: <200505130012.22703.jkeating@j2solutions.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 May 2005 23:47, Panu Matilainen wrote: > Stripping maybe? I know it does break some commercial software I've > repackaged, adding '%define __spec_install_post :' to spec helped. Yah, I finally tracked it down to bsp-strip script causing problems. I'll try your fix and see if that works on a more perm basis. - -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFChFNW4v2HLvE71NURAjt3AJ9zbAy3q6ocOzKkWIg3nWVEtbIKfwCcC/hx IUQuqOe6eKBTGRwkiyGv6oM= =Pt4I -----END PGP SIGNATURE----- From overholt at redhat.com Fri May 13 15:17:29 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 13 May 2005 11:17:29 -0400 Subject: [fedora-java] Re: FC4-re0429.0 known bugs? In-Reply-To: References: <42756961.4030200@redhat.com> <20050502012259.GA31473@redhat.com> Message-ID: <20050513151729.GB608@redhat.com> * Trent Jarvi [2005-05-04 08:34]: > > [...] > Maybe a check should be put in for root as an application hanging the > system is this a critical bug reproducable with current devel i686 > kernels and is not currently recieving attention. How does everyone feel about checking for root in /usr/bin/eclipse? If the user runs it from the menu system, what will happen in that case? Is there an easy way to pop up a message? Andrew From overholt at redhat.com Fri May 13 15:32:43 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 13 May 2005 11:32:43 -0400 Subject: [fedora-java] Re: FC4-re0429.0 known bugs? In-Reply-To: <20050513151729.GB608@redhat.com> References: <42756961.4030200@redhat.com> <20050502012259.GA31473@redhat.com> <20050513151729.GB608@redhat.com> Message-ID: <20050513153243.GE608@redhat.com> * Andrew Overholt [2005-05-13 11:19]: > * Trent Jarvi [2005-05-04 08:34]: > > > > [...] > > Maybe a check should be put in for root as an application hanging the > > system is this a critical bug reproducable with current devel i686 > > kernels and is not currently recieving attention. > > How does everyone feel about checking for root in /usr/bin/eclipse? If After further thought, I think this is a silly bandaid solution. Andrew From notting at redhat.com Fri May 13 15:33:23 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 13 May 2005 11:33:23 -0400 Subject: [fedora-java] Re: FC4-re0429.0 known bugs? In-Reply-To: <20050513151729.GB608@redhat.com> References: <42756961.4030200@redhat.com> <20050502012259.GA31473@redhat.com> <20050513151729.GB608@redhat.com> Message-ID: <20050513153323.GA27450@nostromo.devel.redhat.com> Andrew Overholt (overholt at redhat.com) said: > * Trent Jarvi [2005-05-04 08:34]: > > > > [...] > > Maybe a check should be put in for root as an application hanging the > > system is this a critical bug reproducable with current devel i686 > > kernels and is not currently recieving attention. > > How does everyone feel about checking for root in /usr/bin/eclipse? If > the user runs it from the menu system, what will happen in that case? Is > there an easy way to pop up a message? I would think it's just simpler to figure out why it's hanging the system and fix that... did I miss that part of the discussion? Bill From overholt at redhat.com Fri May 13 15:40:45 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 13 May 2005 11:40:45 -0400 Subject: [fedora-java] Re: FC4-re0429.0 known bugs? In-Reply-To: <20050513153323.GA27450@nostromo.devel.redhat.com> References: <42756961.4030200@redhat.com> <20050502012259.GA31473@redhat.com> <20050513151729.GB608@redhat.com> <20050513153323.GA27450@nostromo.devel.redhat.com> Message-ID: <20050513154045.GF608@redhat.com> * Bill Nottingham [2005-05-13 11:35]: > Andrew Overholt (overholt at redhat.com) said: > > * Trent Jarvi [2005-05-04 08:34]: > > > > > > [...] > > > Maybe a check should be put in for root as an application hanging the > > > system is this a critical bug reproducable with current devel i686 > > > kernels and is not currently recieving attention. > > > > How does everyone feel about checking for root in /usr/bin/eclipse? If > > the user runs it from the menu system, what will happen in that case? Is > > there an easy way to pop up a message? > > I would think it's just simpler to figure out why it's hanging the > system and fix that... did I miss that part of the discussion? Andrew Haley thinks it's a kernel bug since the only way gij could hang the system is by forking very fast (which we don't think is happening here). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152386 Andrew From bugs.michael at gmx.net Mon May 16 10:41:48 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 16 May 2005 12:41:48 +0200 Subject: Fedora Extras: missing bugzilla components Message-ID: <20050516124148.0e1052dc.bugs.michael@gmx.net> An increasing number of packages do not have a component entry in bugzilla! What do you need to do? See if your package is on this list and if it is approved, request addition of a bugzilla component entry on this Wiki page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin GiNaC cdlabelgen cdo cln cvsup dkms enchant enemies-of-carlotta exim-doc exim flumotion freenx gcl ghc gnome-applet-netmon hula kile-i18n lapack milter-greylist mlmmj moin nabi nx octave-forge ots plt-scheme python-cherrypy python-cherrytemplate syslog-ng tdl util-vserver xdaliclock xmms-arts xmms-skins xmms yap From bugs.michael at gmx.net Mon May 16 11:10:35 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 16 May 2005 13:10:35 +0200 Subject: Fedora Extras: packages with EVR upgrade problems Message-ID: <20050516131035.58c5b002.bugs.michael@gmx.net> CVS based automated EVR comparison. EVR of packages built for Fedora Extras Development must be higher than packages for Fedora Extras FC3. Please fix these! In particular where binaries have been released like this: gnome-blog 0:0.8-8.fc3 in FC-3 branch is newer than devel gpredict 0:0.5.0-5 in FC-3 branch is newer than devel inadyn 0:1.90-11.fc3 in FC-3 branch is newer than devel sqlite 0:3.1.2-0.4 in FC-3 branch is newer than devel TeXmacs 0:1.0.5-1 in FC-3 branch is equal to devel audacity 0:1.2.3-3 in FC-3 branch is equal to devel c-ares 0:1.2.1-2 in FC-3 branch is equal to devel cdo 0:0.9.6-2 in FC-3 branch is equal to devel gcl 0:2.6.6-2 in FC-3 branch is equal to devel ghc 0:6.4-8 in FC-3 branch is equal to devel graveman 0:0.3.11-2 in FC-3 branch is equal to devel libcddb 0:1.0.2-1 in FC-3 branch is equal to devel perl-GD-SVG 0:0.25-2 in FC-3 branch is equal to devel perl-Graph 0:0.59-2 in FC-3 branch is equal to devel perl-Heap 0:0.71-1 in FC-3 branch is equal to devel perl-MIME-Lite 0:3.01-2 in FC-3 branch is equal to devel perl-SOAP-Lite 0:0.60a-2 in FC-3 branch is equal to devel perl-SVG 0:2.32-2 in FC-3 branch is equal to devel perl-Text-Shellwords 0:1.07-2 in FC-3 branch is equal to devel perl-XML-Writer 0:0.531-2 in FC-3 branch is equal to devel perl-bioperl 0:1.5.0-3 in FC-3 branch is equal to devel plt-scheme 0:299.100-1 in FC-3 branch is equal to devel python-cherrytemplate 0:1.0.0-1 in FC-3 branch is equal to devel From jpo at di.uminho.pt Mon May 16 11:27:09 2005 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Mon, 16 May 2005 12:27:09 +0100 (WEST) Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050516131035.58c5b002.bugs.michael@gmx.net> References: <20050516131035.58c5b002.bugs.michael@gmx.net> Message-ID: <1063.213.13.91.138.1116242829.squirrel@webmail.lsd.di.uminho.pt> > CVS based automated EVR comparison. EVR of packages built for Fedora > Extras Development must be higher than packages for Fedora Extras FC3. > Please fix these! In particular where binaries have been released like > this: > > ... > perl-GD-SVG 0:0.25-2 in FC-3 branch is equal to devel > perl-Graph 0:0.59-2 in FC-3 branch is equal to devel > perl-Heap 0:0.71-1 in FC-3 branch is equal to devel > perl-MIME-Lite 0:3.01-2 in FC-3 branch is equal to devel > perl-SOAP-Lite 0:0.60a-2 in FC-3 branch is equal to devel > perl-SVG 0:2.32-2 in FC-3 branch is equal to devel > perl-Text-Shellwords 0:1.07-2 in FC-3 branch is equal to devel > perl-XML-Writer 0:0.531-2 in FC-3 branch is equal to devel > perl-bioperl 0:1.5.0-3 in FC-3 branch is equal to devel > ... The BioPerl packages haven't been approved yet. They are still under review. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From tcallawa at redhat.com Mon May 16 13:32:02 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 16 May 2005 08:32:02 -0500 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050516124148.0e1052dc.bugs.michael@gmx.net> References: <20050516124148.0e1052dc.bugs.michael@gmx.net> Message-ID: <1116250322.5350.150.camel@localhost.localdomain> On Mon, 2005-05-16 at 12:41 +0200, Michael Schwendt wrote: > An increasing number of packages do not have a component entry in bugzilla! > > What do you need to do? See if your package is on this list and if it is > approved, request addition of a bugzilla component entry on this Wiki page: > http://fedoraproject.org/wiki/Extras/BugzillaAdmin > dkms DKMS doesn't have a bugzilla entry because its proper maintainer (Matt Domsch) is still trying to get through the legal red tape of Dell and Red Hat. I'll make one now, and pass it over to him when he gets through the system. > lapack This came from Fedora Core, it should have an existing component entry for FC-3 (and I requested that it have one in FE for FC-4). ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From sopwith at redhat.com Mon May 16 20:21:14 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 16 May 2005 16:21:14 -0400 (EDT) Subject: Raising the bar for FC4 Message-ID: Hi all, Fedora Core 4 public release is currently targeted for Monday, June 6. To hit that, we need some time in advance doing QA and final polishing. For test releases that is usually about a week, but this is the final FC4 release so we need a bit of extra time to do the final steps. This means that Monday, May 23 is the final final freeze for FC4. After that, the bar for accepting changes into FC4 is even higher. Fixes will need to be for showstopper bugs (data corruption, crashing programs, and other things that impact a large percentage of users in a major way). I've sent out reminder e-mails to people who currently own FC4Target and FC4Blocker bugs in bugzilla, so you should know if you have specific bugs to address. If you don't have any bugs to address, you can still help by doing test installs of rawhide. I'll also try to get a few intermediate test trees out for people to install. If the plan needs clarification, please let me know! -- Elliot From notting at redhat.com Wed May 18 18:54:59 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 18 May 2005 14:54:59 -0400 Subject: proposal for packaging guidelines: static libraries Message-ID: <20050518185459.GA23607@nostromo.devel.redhat.com> This seems like it could be useful, considering the discussion of a couple of days ago: When to package static libraries -------------------------------- Often, static libraries are built along with shared objects, and will be installed by default with 'make install'. However, there are often cases where it's not practical to ship these as part of the package. Some questions to ask before including static libraries in a package: 1) Are the library's direct dependnecies shipped in static form? For example, if you are packaging libgnome, you may look at what libraries are packaged with gtk2. Since gtk2 doesn't ship static libraries, it doesn't make sense for libgnome to ship them. 2) Is it a build artifact of libtool usage that will never get used? For example, a package might build a gimp plugin, and have both .a and .so objects. However, in the presence of the .so objects, the .a objects will never be used; hence, they shouldn't be shipped. 3) Is it something that would reasonably want to use statically in a program? For example, if it's a library that depends on using plugins for parts of its functionality, it may not make sense. -------------- next part -------------- When to package static libraries -------------------------------- Often, static libraries are built along with shared objects, and will be installed by default with 'make install'. However, there are often cases where it's not practical to ship these as part of the package. Some questions to ask before including static libraries in a package: 1) Are the library's direct dependnecies shipped in static form? For example, if you are packaging libgnome, you may look at what libraries are packaged with gtk2. Since gtk2 doesn't ship static libraries, it doesn't make sense for libgnome to ship them. 2) Is it a build artifact of libtool usage that will never get used? For example, a package might build a gimp plugin, and have both .a and .so objects. However, in the presence of the .so objects, the .a objects will never be used; hence, they shouldn't be shipped. 3) Is it something that would reasonably want to use statically in a program? For example, if it's a library that depends on using plugins for parts of its functionality, it may not make sense. From tcallawa at redhat.com Wed May 18 19:14:45 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 18 May 2005 14:14:45 -0500 Subject: proposal for packaging guidelines: static libraries In-Reply-To: <20050518185459.GA23607@nostromo.devel.redhat.com> References: <20050518185459.GA23607@nostromo.devel.redhat.com> Message-ID: <1116443685.3502.114.camel@localhost.localdomain> On Wed, 2005-05-18 at 14:54 -0400, Bill Nottingham wrote: > This seems like it could be useful, considering the discussion of > a couple of days ago: +1 from me. Unless there is massive disagreement, I'll add this. ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From ivazquez at ivazquez.net Thu May 19 10:02:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 06:02:18 -0400 Subject: mismatch of versions between arches In-Reply-To: <20050512033150.GA2261@nostromo.devel.redhat.com> References: <20050512033150.GA2261@nostromo.devel.redhat.com> Message-ID: <1116496938.7161.54.camel@ignacio.ignacio.lan> On Wed, 2005-05-11 at 23:31 -0400, Bill Nottingham wrote: > clearlooks > gnome-theme-clearlooks Eek! What are these doing in development/ppc? Someone wipe them please. > kphone > ktrack > libosip2 > pam_mysql Interesting. The PPC packages are exactly 1 release behind the i386 and x86_64 packages. Any possible explanations? > python-amara > python-HTMLgen > repoml No sir, I can't see it on these. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 bugs.michael at gmx.net Thu May 19 11:34:57 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 19 May 2005 13:34:57 +0200 Subject: mismatch of versions between arches In-Reply-To: <1116496938.7161.54.camel@ignacio.ignacio.lan> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <1116496938.7161.54.camel@ignacio.ignacio.lan> Message-ID: <20050519133457.2af2c344.bugs.michael@gmx.net> On Thu, 19 May 2005 06:02:18 -0400, Ignacio Vazquez-Abrams wrote: > > kphone > > ktrack > > libosip2 > > pam_mysql > > Interesting. The PPC packages are exactly 1 release behind the i386 and > x86_64 packages. Any possible explanations? "rpm -qpi" is your friend. It should show that these ppc builds come from a different build host when the Fedora Extras build system did only support i386 and x86_64. From ivazquez at ivazquez.net Thu May 19 16:32:34 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 12:32:34 -0400 Subject: mismatch of versions between arches In-Reply-To: <20050519133457.2af2c344.bugs.michael@gmx.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <1116496938.7161.54.camel@ignacio.ignacio.lan> <20050519133457.2af2c344.bugs.michael@gmx.net> Message-ID: <1116520354.7161.62.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 13:34 +0200, Michael Schwendt wrote: > On Thu, 19 May 2005 06:02:18 -0400, Ignacio Vazquez-Abrams wrote: > > > > kphone > > > ktrack > > > libosip2 > > > pam_mysql > > > > Interesting. The PPC packages are exactly 1 release behind the i386 and > > x86_64 packages. Any possible explanations? > > "rpm -qpi" is your friend. It should show that these ppc builds come from > a different build host when the Fedora Extras build system did only > support i386 and x86_64. In that case would anyone take issue with me requesting builds of the current CVS for these 4 packages as well as python-amara, python- HTMLgen, and repoml? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 katzj at redhat.com Thu May 19 16:38:31 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 19 May 2005 12:38:31 -0400 Subject: mismatch of versions between arches In-Reply-To: <1116520354.7161.62.camel@ignacio.ignacio.lan> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <1116496938.7161.54.camel@ignacio.ignacio.lan> <20050519133457.2af2c344.bugs.michael@gmx.net> <1116520354.7161.62.camel@ignacio.ignacio.lan> Message-ID: <1116520711.18941.13.camel@bree.local.net> On Thu, 2005-05-19 at 12:32 -0400, Ignacio Vazquez-Abrams wrote: > In that case would anyone take issue with me requesting builds of the > current CVS for these 4 packages as well as python-amara, python- > HTMLgen, and repoml? Go for it Jeremy From ville.skytta at iki.fi Thu May 19 16:53:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 19 May 2005 19:53:04 +0300 Subject: mismatch of versions between arches In-Reply-To: <1116520711.18941.13.camel@bree.local.net> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <1116496938.7161.54.camel@ignacio.ignacio.lan> <20050519133457.2af2c344.bugs.michael@gmx.net> <1116520354.7161.62.camel@ignacio.ignacio.lan> <1116520711.18941.13.camel@bree.local.net> Message-ID: <1116521584.22482.40.camel@bobcat.mine.nu> On Thu, 2005-05-19 at 12:38 -0400, Jeremy Katz wrote: > On Thu, 2005-05-19 at 12:32 -0400, Ignacio Vazquez-Abrams wrote: > > In that case would anyone take issue with me requesting builds of the > > current CVS for these 4 packages as well as python-amara, python- > > HTMLgen, and repoml? > > Go for it Not needed for noarch packages (including python* and repoml above), they have been taken care of by repo-copying. From ivazquez at ivazquez.net Thu May 19 17:05:57 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 19 May 2005 13:05:57 -0400 Subject: mismatch of versions between arches In-Reply-To: <1116521584.22482.40.camel@bobcat.mine.nu> References: <20050512033150.GA2261@nostromo.devel.redhat.com> <1116496938.7161.54.camel@ignacio.ignacio.lan> <20050519133457.2af2c344.bugs.michael@gmx.net> <1116520354.7161.62.camel@ignacio.ignacio.lan> <1116520711.18941.13.camel@bree.local.net> <1116521584.22482.40.camel@bobcat.mine.nu> Message-ID: <1116522357.7161.64.camel@ignacio.ignacio.lan> On Thu, 2005-05-19 at 19:53 +0300, Ville Skytt? wrote: > On Thu, 2005-05-19 at 12:38 -0400, Jeremy Katz wrote: > > On Thu, 2005-05-19 at 12:32 -0400, Ignacio Vazquez-Abrams wrote: > > > In that case would anyone take issue with me requesting builds of the > > > current CVS for these 4 packages as well as python-amara, python- > > > HTMLgen, and repoml? > > > > Go for it > > Not needed for noarch packages (including python* and repoml above), > they have been taken care of by repo-copying. Fair enough. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Sun May 22 22:13:39 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 22 May 2005 12:13:39 -1000 Subject: umask package policy Message-ID: <42910413.1070502@redhat.com> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73893 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136030 Should we make it a packaging policy that packages must own all directories and files that it installs in order to avoid umask 077 problems like this where the installed software is effectively broken? Also the latter bug is %post creates files with umask 077, leading to similar breakage. Should then the rule be "use umask within %post if it creates files?" Can rpmdiff check for this in the future? Warren Togami wtogami at redhat.com From jkeating at j2solutions.net Sun May 22 22:20:53 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 22 May 2005 15:20:53 -0700 Subject: umask package policy In-Reply-To: <42910413.1070502@redhat.com> References: <42910413.1070502@redhat.com> Message-ID: <1116800454.3532.13.camel@yoda.loki.me> On Sun, 2005-05-22 at 12:13 -1000, Warren Togami wrote: > > Also the latter bug is %post creates files with umask 077, leading to > similar breakage. Should then the rule be "use umask within %post if > it > creates files?" > > Can rpmdiff check for this in the future? Or force the use of %{_install} if you're going to install files by hand, as you then specify the permissions they should be. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From wtogami at redhat.com Sun May 22 22:26:28 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 22 May 2005 12:26:28 -1000 Subject: umask package policy In-Reply-To: <1116800454.3532.13.camel@yoda.loki.me> References: <42910413.1070502@redhat.com> <1116800454.3532.13.camel@yoda.loki.me> Message-ID: <42910714.9010407@redhat.com> Jesse Keating wrote: > On Sun, 2005-05-22 at 12:13 -1000, Warren Togami wrote: > >>Also the latter bug is %post creates files with umask 077, leading to >>similar breakage. Should then the rule be "use umask within %post if >>it >>creates files?" >> >>Can rpmdiff check for this in the future? > > > Or force the use of %{_install} if you're going to install files by > hand, as you then specify the permissions they should be. > This doesn't quite work when %post creates files as the result of some arbitrary command. It is almost never cp there. Warren Togami wtogami at redhat.com From jkeating at j2solutions.net Sun May 22 22:27:06 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 22 May 2005 15:27:06 -0700 Subject: umask package policy In-Reply-To: <42910714.9010407@redhat.com> References: <42910413.1070502@redhat.com> <1116800454.3532.13.camel@yoda.loki.me> <42910714.9010407@redhat.com> Message-ID: <1116800826.3532.15.camel@yoda.loki.me> On Sun, 2005-05-22 at 12:26 -1000, Warren Togami wrote: > > This doesn't quite work when %post creates files as the result of > some > arbitrary command. It is almost never cp there. Most excellent point. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From wtogami at redhat.com Sun May 22 22:40:09 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 22 May 2005 12:40:09 -1000 Subject: %doc package policy Message-ID: <42910A49.3080201@redhat.com> By FC5, we should make it so nothing in our software relies on the existence of %doc installed files, that is stuff that ends up in /usr/share/doc/%{name}-%{version}-%{release}. rpm --excludedocs should create an installed system that works exactly the same during runtime. This is already the case for 99.99% of our packages, so complying with this rule would require very few changes. Can we come to agreement on this and add this to packaging policy? Warren Togami wtogami at redhat.com From mattdm at mattdm.org Sun May 22 23:24:02 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 22 May 2005 19:24:02 -0400 Subject: %doc package policy In-Reply-To: <42910A49.3080201@redhat.com> References: <42910A49.3080201@redhat.com> Message-ID: <20050522232402.GA1999@jadzia.bu.edu> On Sun, May 22, 2005 at 12:40:09PM -1000, Warren Togami wrote: > By FC5, we should make it so nothing in our software relies on the > existence of %doc installed files, that is stuff that ends up in > /usr/share/doc/%{name}-%{version}-%{release}. [...] > Can we come to agreement on this and add this to packaging policy? Sounds sane to me. The location of indexhtml will have to change.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 72 degrees Fahrenheit. From otaylor at redhat.com Sun May 22 23:32:58 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sun, 22 May 2005 19:32:58 -0400 Subject: %doc package policy In-Reply-To: <42910A49.3080201@redhat.com> References: <42910A49.3080201@redhat.com> Message-ID: <1116804778.16802.28.camel@huygens> On Sun, 2005-05-22 at 12:40 -1000, Warren Togami wrote: > By FC5, we should make it so nothing in our software relies on the > existence of %doc installed files, that is stuff that ends up in > /usr/share/doc/%{name}-%{version}-%{release}. > > rpm --excludedocs should create an installed system that works exactly > the same during runtime. This is already the case for 99.99% of our > packages, so complying with this rule would require very few changes. > > Can we come to agreement on this and add this to packaging policy? What does "rely on" mean here? The "Help" menu command in fontforge accesses HTML files that are in the %doc directory. I think it actually falls back to the web if it doesn't find the files, but say it didn't and displayed an error? Is that relying on the %doc files? Regards, Owen -------------- 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 toshio at tiki-lounge.com Mon May 23 00:04:16 2005 From: toshio at tiki-lounge.com (Toshio) Date: Sun, 22 May 2005 20:04:16 -0400 Subject: %doc package policy In-Reply-To: <1116804778.16802.28.camel@huygens> References: <42910A49.3080201@redhat.com> <1116804778.16802.28.camel@huygens> Message-ID: <1116806658.16198.200.camel@Madison.badger.com> On Sun, 2005-05-22 at 19:32 -0400, Owen Taylor wrote: > On Sun, 2005-05-22 at 12:40 -1000, Warren Togami wrote: > > By FC5, we should make it so nothing in our software relies on the > > existence of %doc installed files, that is stuff that ends up in > > /usr/share/doc/%{name}-%{version}-%{release}. > > > > rpm --excludedocs should create an installed system that works exactly > > the same during runtime. This is already the case for 99.99% of our > > packages, so complying with this rule would require very few changes. > > > > Can we come to agreement on this and add this to packaging policy? > > What does "rely on" mean here? The "Help" menu command in fontforge > accesses HTML files that are in the %doc directory. I think it actually > falls back to the web if it doesn't find the files, but say it > didn't and displayed an error? Is that relying on the %doc files? > I know of at least one other packsge that does this. I think this is relying on the %doc file and would have to change under this policy. There has also been the occasional tendency to punt on deciding whether optional/example programs, init scripts, etc are useful enough to be in the package by putting them in %doc. I think under this policy we need to be more careful about doing this. Neither of these is a reason not to implement this policy. -Toshio -- ______S______U______B______L______I______M______I______N______A______L______ t o s h i o @ t i k i - l o u n g e . c o m GA->ME 1999 -------------- 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 Mon May 23 01:46:10 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 22 May 2005 15:46:10 -1000 Subject: %doc package policy In-Reply-To: <1116806658.16198.200.camel@Madison.badger.com> References: <42910A49.3080201@redhat.com> <1116804778.16802.28.camel@huygens> <1116806658.16198.200.camel@Madison.badger.com> Message-ID: <429135E2.9010101@redhat.com> Toshio wrote: > On Sun, 2005-05-22 at 19:32 -0400, Owen Taylor wrote: > >>On Sun, 2005-05-22 at 12:40 -1000, Warren Togami wrote: >> >>>By FC5, we should make it so nothing in our software relies on the >>>existence of %doc installed files, that is stuff that ends up in >>>/usr/share/doc/%{name}-%{version}-%{release}. >>> >>>rpm --excludedocs should create an installed system that works exactly >>>the same during runtime. This is already the case for 99.99% of our >>>packages, so complying with this rule would require very few changes. >>> >>>Can we come to agreement on this and add this to packaging policy? >> >>What does "rely on" mean here? The "Help" menu command in fontforge >>accesses HTML files that are in the %doc directory. I think it actually >>falls back to the web if it doesn't find the files, but say it >>didn't and displayed an error? Is that relying on the %doc files? >> > > I know of at least one other packsge that does this. I think this is > relying on the %doc file and would have to change under this policy. > > There has also been the occasional tendency to punt on deciding whether > optional/example programs, init scripts, etc are useful enough to be in > the package by putting them in %doc. I think under this policy we need > to be more careful about doing this. > > Neither of these is a reason not to implement this policy. > > -Toshio Note that not everything under /usr/share/doc is %doc. This rule is only talking about stuff marked as %doc, not stuff under %files. /usr/share/doc can contain stuff listed in %files which is not excluded by rpm --excludedocs, I believe all the docs in /usr/share/doc/HTML/ are listed under %files instead of %doc. %doc should be for truly optional stuff that is not needed during runtime. IMHO marking online documentation as %doc isn't great, because it puts it into a versioned directory. Versioned directory handling means more complexity when they must be referenced by applications. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155425 This is an example that would be disallowed under this rule. The RPM gpg keys are clearly not documentation. It is currently included in the package as "%doc R*". Warren Togami wtogami at redhat.com From pnasrat at redhat.com Mon May 23 15:02:03 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Mon, 23 May 2005 11:02:03 -0400 Subject: Stricter rpmbuild with unpackaged files Message-ID: <1116860524.16089.1.camel@enki.eridu> The unpackaged files checks now catch unpackaged symlinks. As per FC4 tracker request https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108778 Paul From ville.skytta at iki.fi Mon May 23 17:32:35 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 May 2005 20:32:35 +0300 Subject: umask package policy In-Reply-To: <42910413.1070502@redhat.com> References: <42910413.1070502@redhat.com> Message-ID: <1116869555.4882.15.camel@bobcat.mine.nu> On Sun, 2005-05-22 at 12:13 -1000, Warren Togami wrote: > Should we make it a packaging policy that packages must own all > directories and files that it installs in order to avoid umask 077 > problems like this where the installed software is effectively broken? +1, although I thought that already is a policy at least in Extras. But not _all_ directories it installs, only those that are not owned by its prerequisite packages. > Also the latter bug is %post creates files with umask 077, leading to > similar breakage. Should then the rule be "use umask within %post if it > creates files?" I think it would be simpler and cleaner to have rpm execute all scriptlets with let's say a 022 umask, and make that umask value configurable in eg. /usr/lib/rpm(/$vendor)/macros. > Can rpmdiff check for this in the future? Are you referring to the rpmdiff distributed with rpmlint, or something else? From tmraz at redhat.com Mon May 23 17:37:47 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 23 May 2005 19:37:47 +0200 Subject: Guidelines for %config and %config(noreplace) Message-ID: <1116869867.5930.48.camel@perun.redhat.usu> Are there any guidelines when to use %config and when %config (noreplace)? If you look at this bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158568 Currently in FC-3 the ca-bundle.pem file is not %config at all. This is obviously wrong because if sysadmin changes this file (and it's legitimate to do so) he will lose his changes after openssl update. However it's questionable if it should be %config(noreplace) because then he will not get the changes (new CA certificates) on update. -- Tomas Mraz From bugs.michael at gmx.net Mon May 23 17:45:29 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 23 May 2005 19:45:29 +0200 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <1116869867.5930.48.camel@perun.redhat.usu> References: <1116869867.5930.48.camel@perun.redhat.usu> Message-ID: <20050523194529.52b5bd6f.bugs.michael@gmx.net> On Mon, 23 May 2005 19:37:47 +0200, Tomas Mraz wrote: > Are there any guidelines when to use %config and when %config > (noreplace)? > If you look at this bug report: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158568 > > Currently in FC-3 the ca-bundle.pem file is not %config at all. This is > obviously wrong because if sysadmin changes this file (and it's > legitimate to do so) he will lose his changes after openssl update. > > However it's questionable if it should be %config(noreplace) because > then he will not get the changes (new CA certificates) on update. What's more important...? [ ] sysadmin gets an *.rpmsave config file during upgrade [ ] sysadmin gets an *.rpmnew config file during upgrade From ville.skytta at iki.fi Mon May 23 17:49:35 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 May 2005 20:49:35 +0300 Subject: %doc package policy In-Reply-To: <429135E2.9010101@redhat.com> References: <42910A49.3080201@redhat.com> <1116804778.16802.28.camel@huygens> <1116806658.16198.200.camel@Madison.badger.com> <429135E2.9010101@redhat.com> Message-ID: <1116870575.4882.29.camel@bobcat.mine.nu> On Sun, 2005-05-22 at 15:46 -1000, Warren Togami wrote: > Note that not everything under /usr/share/doc is %doc. Yes it is, at least with the current FC rpm configuration. rpmbuild marks everything in the following dirs automatically as documentation, which is the same as if they had been explicitly marked with %doc in the specfile (see build/files.c): /usr/doc, /usr/man, /usr/info, /usr/share/man, /usr/share/info, %{_docdir}, %{_mandir}, %{_infodir}, %{_javadocdir} > This rule is > only talking about stuff marked as %doc, not stuff under %files. > /usr/share/doc can contain stuff listed in %files which is not excluded > by rpm --excludedocs, I believe all the docs in /usr/share/doc/HTML/ are > listed under %files instead of %doc. %doc should be for truly optional > stuff that is not needed during runtime. I guess you're actually referring to the special case magic %doc directive which copies files from the buildroot to %{_docdir}/%{name}-%{version} if the file paths that are its arguments don't begin with a "/". %doc has two meanings depending on its arguments, and it is always written in the %files section of a specfile. From jdennis at redhat.com Mon May 23 17:59:33 2005 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 May 2005 13:59:33 -0400 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <1116869867.5930.48.camel@perun.redhat.usu> References: <1116869867.5930.48.camel@perun.redhat.usu> Message-ID: <1116871174.13925.45.camel@localhost.localdomain> On Mon, 2005-05-23 at 19:37 +0200, Tomas Mraz wrote: > Are there any guidelines when to use %config and when %config > (noreplace)? > If you look at this bug report: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158568 > > Currently in FC-3 the ca-bundle.pem file is not %config at all. This is > obviously wrong because if sysadmin changes this file (and it's > legitimate to do so) he will lose his changes after openssl update. > > However it's questionable if it should be %config(noreplace) because > then he will not get the changes (new CA certificates) on update. I believe the way to think about this is by asking the question, "Did the sysadmin change the file?" If they did then rpm shouldn't overwrite his/her explicition modification. If the config file was unaltered then rpm should install the latest version of the file thus getting the updates. This is precisely the behavior of config noreplace, which I believe in this instance is probably the optimal behavior. If a sys admin has altered a config file they are probably aware of the possble existence of a .rpmnew file and are aware of its implications. -- John Dennis From tmraz at redhat.com Mon May 23 18:18:47 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 23 May 2005 20:18:47 +0200 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <1116871174.13925.45.camel@localhost.localdomain> References: <1116869867.5930.48.camel@perun.redhat.usu> <1116871174.13925.45.camel@localhost.localdomain> Message-ID: <1116872327.5930.54.camel@perun.redhat.usu> On Mon, 2005-05-23 at 13:59 -0400, John Dennis wrote: > On Mon, 2005-05-23 at 19:37 +0200, Tomas Mraz wrote: > > Are there any guidelines when to use %config and when %config > > (noreplace)? > > If you look at this bug report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158568 > > > > Currently in FC-3 the ca-bundle.pem file is not %config at all. This is > > obviously wrong because if sysadmin changes this file (and it's > > legitimate to do so) he will lose his changes after openssl update. > > > > However it's questionable if it should be %config(noreplace) because > > then he will not get the changes (new CA certificates) on update. > > I believe the way to think about this is by asking the question, "Did > the sysadmin change the file?" If they did then rpm shouldn't overwrite > his/her explicition modification. If the config file was unaltered then > rpm should install the latest version of the file thus getting the > updates. This is precisely the behavior of config noreplace, which I > believe in this instance is probably the optimal behavior. > > If a sys admin has altered a config file they are probably aware of the > possble existence of a .rpmnew file and are aware of its implications. Generally I would agree, the question is if the ca-bundle.pem is or isn't normal config file or if it's a little bit special in this regard. But I'm inclined to make it %config(noreplace). -- Tomas Mraz From ville.skytta at iki.fi Mon May 23 18:31:09 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 23 May 2005 21:31:09 +0300 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <20050523194529.52b5bd6f.bugs.michael@gmx.net> References: <1116869867.5930.48.camel@perun.redhat.usu> <20050523194529.52b5bd6f.bugs.michael@gmx.net> Message-ID: <1116873069.4882.60.camel@bobcat.mine.nu> On Mon, 2005-05-23 at 19:45 +0200, Michael Schwendt wrote: > On Mon, 23 May 2005 19:37:47 +0200, Tomas Mraz wrote: > > > Are there any guidelines when to use %config and when %config > > (noreplace)? How about "Always use noreplace unless your best guess is that it will break things"? AFAICS there are really only two situations where noreplace is likely to break stuff: 1) An app is being upgraded from an earlier version which had incompatible config files which will break the new version. 2) An app is being installed for the first time from a rpm, and a file marked as config in the package was already present on the system before installing the package, AND it's not likely that the app being installed would work with the config file that was already present on the system. > > If you look at this bug report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158568 > > > > Currently in FC-3 the ca-bundle.pem file is not %config at all. This is > > obviously wrong because if sysadmin changes this file (and it's > > legitimate to do so) he will lose his changes after openssl update. > > > > However it's questionable if it should be %config(noreplace) because > > then he will not get the changes (new CA certificates) on update. > > What's more important...? > > [ ] sysadmin gets an *.rpmsave config file during upgrade > [ ] sysadmin gets an *.rpmnew config file during upgrade (also consider the *.rpmorig case here) If a sysadmin has installed new CA certs into ca-bundle.pem, most likely it has been done in order to get something working. Not getting the new CA certs is less likely to break stuff and thus less evil IMO. Optimally, the contents of the old and new ca-bundle.pem should be intelligently merged (ha!) on upgrades. Not sure if it's worth even trying to implement that though. From jspaleta at gmail.com Mon May 23 18:36:43 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 23 May 2005 14:36:43 -0400 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <1116871174.13925.45.camel@localhost.localdomain> References: <1116869867.5930.48.camel@perun.redhat.usu> <1116871174.13925.45.camel@localhost.localdomain> Message-ID: <604aa791050523113678a694d8@mail.gmail.com> On 5/23/05, John Dennis wrote: > I believe the way to think about this is by asking the question, "Did > the sysadmin change the file?" If they did then rpm shouldn't overwrite > his/her explicition modification What if the config file format has changed to the extent that the packager knows that old config files are no longer valid and by using the old config file format the application or service fails to start at all? Don't you need to replace the old configs, regardless of modified state? Isn't situations like this one of the reasons why rpmsave files are an option packagers have? > If a sys admin has altered a config file they are probably aware of the > possble existence of a .rpmnew file and are aware of its implications. No no no... there are many system-config-* gui tools that novice admins and hobbiests are relying on. I find the assumption that the bulk of fedora's userbase are experienced admins who know about the rpmnew/rpmsave feature errenous. The system-config-* tools in the distro hide the details of the config file locations and many novice hobbiests who install fedora have absolutely no clue about the rpmnew/rpmsave feature of rpm. yum nor up2date for example make no attempt to notify about when these files are created, nor is their existence testable via rpm queries or reporting facilities. The only way you know about these files is by filesystem indexing or searching. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158575 You could argue that rhel admins tend to be experienced enough to know about this sort of thing..but they do so because they've learned it from other means..like training classes..or documentation...and not from information given to them as part of tool interaction when using the system. And if there is one truth that I hold dear its this, a large chunk of the fedora userbase don't go out of their way to read documentation unless forced to. And in the case of rpmnew/rpmsave specifically, i'm not even sure there is in distro documentation like a manpage or infopage that describes this feature at all. -jef From tmraz at redhat.com Mon May 23 18:40:07 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 23 May 2005 20:40:07 +0200 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <1116873069.4882.60.camel@bobcat.mine.nu> References: <1116869867.5930.48.camel@perun.redhat.usu> <20050523194529.52b5bd6f.bugs.michael@gmx.net> <1116873069.4882.60.camel@bobcat.mine.nu> Message-ID: <1116873608.5930.56.camel@perun.redhat.usu> On Mon, 2005-05-23 at 21:31 +0300, Ville Skytt? wrote: > On Mon, 2005-05-23 at 19:45 +0200, Michael Schwendt wrote: > > On Mon, 23 May 2005 19:37:47 +0200, Tomas Mraz wrote: > > > > > Are there any guidelines when to use %config and when %config > > > (noreplace)? > > How about "Always use noreplace unless your best guess is that it will > break things"? AFAICS there are really only two situations where > noreplace is likely to break stuff: > > 1) An app is being upgraded from an earlier version which had > incompatible config files which will break the new version. > > 2) An app is being installed for the first time from a rpm, and a file > marked as config in the package was already present on the system before > installing the package, AND it's not likely that the app being installed > would work with the config file that was already present on the system. That's exactly what I wanted to hear, thanks Ville. Could someone with rights put this to http://fedoraproject.org/wiki/PackagingGuidelines -- Tomas Mraz From shahms at shahms.com Mon May 23 19:01:50 2005 From: shahms at shahms.com (Shahms King) Date: Mon, 23 May 2005 12:01:50 -0700 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <1116869867.5930.48.camel@perun.redhat.usu> References: <1116869867.5930.48.camel@perun.redhat.usu> Message-ID: <4292289E.1030600@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tomas Mraz wrote: | Are there any guidelines when to use %config and when %config | (noreplace)? | If you look at this bug report: | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158568 | | Currently in FC-3 the ca-bundle.pem file is not %config at all. This is | obviously wrong because if sysadmin changes this file (and it's | legitimate to do so) he will lose his changes after openssl update. | | However it's questionable if it should be %config(noreplace) because | then he will not get the changes (new CA certificates) on update. | Isn't /usr/share/* the wrong place for a config file? In a similar vein, wasn't there a recent thread about moving SSL keys into /etc/ssl/? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCkiie/qs2NkWy11sRAsSIAKDA8f0pWtqvpschjhVIZ3B5P5N8zwCgn2QF 7gxYkExsvi/GO7xCM9ssOoI= =FLNK -----END PGP SIGNATURE----- From jdennis at redhat.com Mon May 23 19:09:44 2005 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 May 2005 15:09:44 -0400 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <4292289E.1030600@shahms.com> References: <1116869867.5930.48.camel@perun.redhat.usu> <4292289E.1030600@shahms.com> Message-ID: <1116875384.13925.79.camel@localhost.localdomain> On Mon, 2005-05-23 at 12:01 -0700, Shahms King wrote: > Isn't /usr/share/* the wrong place for a config file? In a similar vein, > wasn't there a recent thread about moving SSL keys into /etc/ssl/? Yes, and it was moved to: /etc/pki/tls/certs/ca-bundle.crt but note this is only for FC4 and beyond. -- John Dennis From tmraz at redhat.com Mon May 23 19:13:39 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 23 May 2005 21:13:39 +0200 Subject: Guidelines for %config and %config(noreplace) In-Reply-To: <4292289E.1030600@shahms.com> References: <1116869867.5930.48.camel@perun.redhat.usu> <4292289E.1030600@shahms.com> Message-ID: <1116875619.5930.58.camel@perun.redhat.usu> On Mon, 2005-05-23 at 12:01 -0700, Shahms King wrote: > Tomas Mraz wrote: > | Are there any guidelines when to use %config and when %config > | (noreplace)? > | If you look at this bug report: > | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158568 > | > Isn't /usr/share/* the wrong place for a config file? In a similar vein, > wasn't there a recent thread about moving SSL keys into /etc/ssl/? This is bug report against FC3. -- Tomas Mraz From janina at rednote.net Mon May 23 19:30:26 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 23 May 2005 15:30:26 -0400 Subject: Bug 124248 Fixed--Can we have in FC4? Message-ID: <20050523193026.GA12493@rednote.net> Lee Bcc: Subject: Re: Raising the bar for FC4 Reply-To: In-Reply-To: X-Operating-System: Linux concerto.rednote.net 2.6.11-1.14_FC3spksmp Organization: Capital Accessibility LLC (http://www.CapitalAccessibility.com) X-PGP-Key: http://www.CapitalAccessibility.com/JaninaSajka_gpg_key.html I understand the telnet bug fix is now in CVS, so can this fix please make FC4? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124248 Those of us who really need telnet install, REALLY need it. For us it's critical. I may be mistaken, but I believe it does not impact anyone who isn't actually needing it. Thanks. Thanks also to Jeremy Katz for getting the fix in, and to Jim Cornette for his help reporting the problem in the first instance. Elliot Lee writes: > Hi all, > > Fedora Core 4 public release is currently targeted for Monday, June 6. To > hit that, we need some time in advance doing QA and final polishing. For > test releases that is usually about a week, but this is the final FC4 > release so we need a bit of extra time to do the final steps. > > This means that Monday, May 23 is the final final freeze for FC4. After > that, the bar for accepting changes into FC4 is even higher. Fixes will > need to be for showstopper bugs (data corruption, crashing programs, and > other things that impact a large percentage of users in a major way). I've > sent out reminder e-mails to people who currently own FC4Target and > FC4Blocker bugs in bugzilla, so you should know if you have specific bugs > to address. > > If you don't have any bugs to address, you can still help by doing test > installs of rawhide. I'll also try to get a few intermediate test trees > out for people to install. > > If the plan needs clarification, please let me know! > -- Elliot > > -- > fedora-test-list mailing list > fedora-test-list at redhat.com > To unsubscribe: > http://www.redhat.com/mailman/listinfo/fedora-test-list -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From janina at rednote.net Mon May 23 19:31:08 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 23 May 2005 15:31:08 -0400 Subject: Bug 124248 Fixed--Can we have in FC4? Message-ID: <20050523193026.GA12493@rednote.net> Lee Bcc: Subject: Re: Raising the bar for FC4 Reply-To: In-Reply-To: X-Operating-System: Linux concerto.rednote.net 2.6.11-1.14_FC3spksmp Organization: Capital Accessibility LLC (http://www.CapitalAccessibility.com) X-PGP-Key: http://www.CapitalAccessibility.com/JaninaSajka_gpg_key.html I understand the telnet bug fix is now in CVS, so can this fix please make FC4? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124248 Those of us who really need telnet install, REALLY need it. For us it's critical. I may be mistaken, but I believe it does not impact anyone who isn't actually needing it. Thanks. Thanks also to Jeremy Katz for getting the fix in, and to Jim Cornette for his help reporting the problem in the first instance. Elliot Lee writes: > Hi all, > > Fedora Core 4 public release is currently targeted for Monday, June 6. To > hit that, we need some time in advance doing QA and final polishing. For > test releases that is usually about a week, but this is the final FC4 > release so we need a bit of extra time to do the final steps. > > This means that Monday, May 23 is the final final freeze for FC4. After > that, the bar for accepting changes into FC4 is even higher. Fixes will > need to be for showstopper bugs (data corruption, crashing programs, and > other things that impact a large percentage of users in a major way). I've > sent out reminder e-mails to people who currently own FC4Target and > FC4Blocker bugs in bugzilla, so you should know if you have specific bugs > to address. > > If you don't have any bugs to address, you can still help by doing test > installs of rawhide. I'll also try to get a few intermediate test trees > out for people to install. > > If the plan needs clarification, please let me know! > -- Elliot > > -- > fedora-test-list mailing list > fedora-test-list at redhat.com > To unsubscribe: > http://www.redhat.com/mailman/listinfo/fedora-test-list -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From wtogami at redhat.com Mon May 23 20:20:43 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 May 2005 10:20:43 -1000 Subject: umask package policy In-Reply-To: <1116869555.4882.15.camel@bobcat.mine.nu> References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> Message-ID: <42923B1B.80408@redhat.com> Ville Skytt? wrote: > On Sun, 2005-05-22 at 12:13 -1000, Warren Togami wrote: > > >>Should we make it a packaging policy that packages must own all >>directories and files that it installs in order to avoid umask 077 >>problems like this where the installed software is effectively broken? > > > +1, although I thought that already is a policy at least in Extras. But > not _all_ directories it installs, only those that are not owned by its > prerequisite packages. > Hmm you are right, but that makes it more difficult to make an automated test. I guess both tests will require a chroot and installing all deps. > >>Also the latter bug is %post creates files with umask 077, leading to >>similar breakage. Should then the rule be "use umask within %post if it >>creates files?" > > > I think it would be simpler and cleaner to have rpm execute all > scriptlets with let's say a 022 umask, and make that umask value > configurable in eg. /usr/lib/rpm(/$vendor)/macros. > This isn't a solution for older distributions, this umask problem is troubling for RHEL too, and we can't push this rpm change there. > >>Can rpmdiff check for this in the future? > > > Are you referring to the rpmdiff distributed with rpmlint, or something > else? Automated tests in general. Warren Togami wtogami at redhat.com From enrico.scholz at informatik.tu-chemnitz.de Mon May 23 21:11:13 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 23 May 2005 23:11:13 +0200 Subject: umask package policy In-Reply-To: <42923B1B.80408@redhat.com> (Warren Togami's message of "Mon, 23 May 2005 10:20:43 -1000") References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> <42923B1B.80408@redhat.com> Message-ID: <87k6lpps0e.fsf@kosh.bigo.ensc.de> wtogami at redhat.com (Warren Togami) writes: >>> Should we make it a packaging policy that packages must own all >>> directories and files that it installs in order to avoid umask 077 >>> problems like this where the installed software is effectively >>> broken? >> +1, although I thought that already is a policy at least in Extras. >> But not _all_ directories it installs, only those that are not owned >> by its prerequisite packages. Exactly; and to nitpick: simple 'Requires:' do not suffice, but 'Requires(pre):' (and Requires(postun): ones) are needed. > Hmm you are right, but that makes it more difficult to make an automated > test. An automated test would have to ignore lot of exceptions; e.g. there was never found a solution for all the language dirs in /usr/share/man or in /usr/share/locale. > I guess both tests will require a chroot and installing all deps. Not really; just an rpmdb with all available packages. rpmDirectoryCheck can do such a check but does not work well with ambiguous deps and requires manual adjustments for them. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ville.skytta at iki.fi Mon May 23 21:42:18 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 24 May 2005 00:42:18 +0300 Subject: umask package policy In-Reply-To: <87k6lpps0e.fsf@kosh.bigo.ensc.de> References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> <42923B1B.80408@redhat.com> <87k6lpps0e.fsf@kosh.bigo.ensc.de> Message-ID: <1116884538.1060.16.camel@bobcat.mine.nu> On Mon, 2005-05-23 at 23:11 +0200, Enrico Scholz wrote: > wtogami at redhat.com (Warren Togami) writes: > > >>> Should we make it a packaging policy that packages must own all > >>> directories and files that it installs in order to avoid umask 077 > >>> problems like this where the installed software is effectively > >>> broken? > >> +1, although I thought that already is a policy at least in Extras. > >> But not _all_ directories it installs, only those that are not owned > >> by its prerequisite packages. > > Exactly; and to nitpick: simple 'Requires:' do not suffice, but > 'Requires(pre):' (and Requires(postun): ones) are needed. Using context marked dependencies like Requires(pre) to "solve" this is abuse, please don't do that. Plain Requires is fine as long as there are no dependency loops involved. If there are dependency loops, most bets are off anyway. OTOH, I'm told the win-over-Requires magic of PreReq got added back to FC4 rpm, it could be useful in some dep loop cases. http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED From ville.skytta at iki.fi Mon May 23 21:43:47 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 24 May 2005 00:43:47 +0300 Subject: umask package policy In-Reply-To: <42923B1B.80408@redhat.com> References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> <42923B1B.80408@redhat.com> Message-ID: <1116884627.1060.19.camel@bobcat.mine.nu> On Mon, 2005-05-23 at 10:20 -1000, Warren Togami wrote: > Ville Skytt? wrote: > > I think it would be simpler and cleaner to have rpm execute all > > scriptlets with let's say a 022 umask, and make that umask value > > configurable in eg. /usr/lib/rpm(/$vendor)/macros. > > This isn't a solution for older distributions, this umask problem is > troubling for RHEL too, and we can't push this rpm change there. Do you think this would be useful to RFE in Bugzilla for future rpm releases anyway? From wtogami at redhat.com Mon May 23 21:59:47 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 23 May 2005 11:59:47 -1000 Subject: kernel-devel and kernel-smp-devel Message-ID: <42925253.2040306@redhat.com> I just noticed that yum is Installing kernel-devel but Updating kernel-smp-devel. Shouldn't it be Install on both? Warren Togami wtogami at redhat.com From enrico.scholz at informatik.tu-chemnitz.de Mon May 23 22:00:38 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 24 May 2005 00:00:38 +0200 Subject: umask package policy In-Reply-To: <1116884538.1060.16.camel@bobcat.mine.nu> (Ville Skytt's message of "Tue, 24 May 2005 00:42:18 +0300") References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> <42923B1B.80408@redhat.com> <87k6lpps0e.fsf@kosh.bigo.ensc.de> <1116884538.1060.16.camel@bobcat.mine.nu> Message-ID: <87fywdppq1.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> >> +1, although I thought that already is a policy at least in Extras. >> >> But not _all_ directories it installs, only those that are not >> >> owned by its prerequisite packages. >> >> Exactly; and to nitpick: simple 'Requires:' do not suffice, but >> 'Requires(pre):' (and Requires(postun): ones) are needed. > > Using context marked dependencies like Requires(pre) to "solve" this is > abuse, please don't do that. Why abuse? There is no other way to say 'I require directory /foo before my files will be installed' for a package. rpm could introduce a special 'filesystem' classifier so that the two 'Requires(pre|postun)' can be replaced by a single one. But that's not backward compatible and will probably never be implemented. > Plain Requires is fine as long as there are no dependency loops > involved. Why should I trust in some preconditions which can never be guaranted instead of enforcing the correct behavior? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 476 bytes Desc: not available URL: From jspaleta at gmail.com Mon May 23 22:01:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 23 May 2005 18:01:09 -0400 Subject: kernel-devel and kernel-smp-devel In-Reply-To: <42925253.2040306@redhat.com> References: <42925253.2040306@redhat.com> Message-ID: <604aa791050523150150541a9b@mail.gmail.com> On 5/23/05, Warren Togami wrote: > I just noticed that yum is Installing kernel-devel but Updating > kernel-smp-devel. Shouldn't it be Install on both? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155988 From ville.skytta at iki.fi Tue May 24 06:27:18 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 24 May 2005 09:27:18 +0300 Subject: umask package policy In-Reply-To: <87fywdppq1.fsf@kosh.bigo.ensc.de> References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> <42923B1B.80408@redhat.com> <87k6lpps0e.fsf@kosh.bigo.ensc.de> <1116884538.1060.16.camel@bobcat.mine.nu> <87fywdppq1.fsf@kosh.bigo.ensc.de> Message-ID: <1116916038.1060.57.camel@bobcat.mine.nu> On Tue, 2005-05-24 at 00:00 +0200, Enrico Scholz wrote: > ville.skytta at iki.fi (Ville Skytt?) writes: > > > Using context marked dependencies like Requires(pre) to "solve" this is > > abuse, please don't do that. > > Why abuse? There is no other way to say 'I require directory /foo before > my files will be installed' for a package. "Requires(pre): /foo" does not say that. It says "directory /foo is required until my %pre script has completed". See the description in the max-rpm snapshot (link in my previous mail). > rpm could introduce a special > 'filesystem' classifier so that the two 'Requires(pre|postun)' can be > replaced by a single one. That would be replacing apples with oranges. Such replacement would make no sense because they mean different things. > But that's not backward compatible and will > probably never be implemented. No need to implement that because "Requires: /foo" and "PreReq: /foo" already accomplish what you described above. > > Plain Requires is fine as long as there are no dependency loops > > involved. > > Why should I trust in some preconditions which can never be guaranted > instead of enforcing the correct behavior? You are using side effects of tools not meant to enforce what you're trying to achieve. In other words, abusing them. What's wrong with plain Requires or PreReq? From enrico.scholz at informatik.tu-chemnitz.de Tue May 24 08:50:12 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 24 May 2005 10:50:12 +0200 Subject: umask package policy In-Reply-To: <1116916038.1060.57.camel@bobcat.mine.nu> (Ville Skytt's message of "Tue, 24 May 2005 09:27:18 +0300") References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> <42923B1B.80408@redhat.com> <87k6lpps0e.fsf@kosh.bigo.ensc.de> <1116884538.1060.16.camel@bobcat.mine.nu> <87fywdppq1.fsf@kosh.bigo.ensc.de> <1116916038.1060.57.camel@bobcat.mine.nu> Message-ID: <873bsd3t4r.fsf@kosh.bigo.ensc.de> ville.skytta at iki.fi (Ville Skytt?) writes: >> > Using context marked dependencies like Requires(pre) to "solve" this is >> > abuse, please don't do that. >> >> Why abuse? There is no other way to say 'I require directory /foo before >> my files will be installed' for a package. > > "Requires(pre): /foo" does not say that. It says "directory /foo is > required until my %pre script has completed". See the description in > the max-rpm snapshot (link in my previous mail). ok; then a third 'Requires:' should be added. But that's implicated by 'Requires(...)' in the current tools. > You are using side effects of tools not meant to enforce what you're > trying to achieve. In other words, abusing them. What's wrong with > plain Requires or PreReq? 'Requires:' does not guarantee that the directory exists when the package is installed. Semantic of 'PreReq' is not clear to me and afaik, it is deprecated and should be replaced by 'Requires(...):'. Enrico From ville.skytta at iki.fi Tue May 24 13:23:37 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 24 May 2005 16:23:37 +0300 Subject: umask package policy In-Reply-To: <873bsd3t4r.fsf@kosh.bigo.ensc.de> References: <42910413.1070502@redhat.com> <1116869555.4882.15.camel@bobcat.mine.nu> <42923B1B.80408@redhat.com> <87k6lpps0e.fsf@kosh.bigo.ensc.de> <1116884538.1060.16.camel@bobcat.mine.nu> <87fywdppq1.fsf@kosh.bigo.ensc.de> <1116916038.1060.57.camel@bobcat.mine.nu> <873bsd3t4r.fsf@kosh.bigo.ensc.de> Message-ID: <1116941017.1060.92.camel@bobcat.mine.nu> On Tue, 2005-05-24 at 10:50 +0200, Enrico Scholz wrote: > ville.skytta at iki.fi (Ville Skytt?) writes: > > >> > Using context marked dependencies like Requires(pre) to "solve" this is > >> > abuse, please don't do that. > >> > >> Why abuse? There is no other way to say 'I require directory /foo before > >> my files will be installed' for a package. > > > > "Requires(pre): /foo" does not say that. It says "directory /foo is > > required until my %pre script has completed". See the description in > > the max-rpm snapshot (link in my previous mail). > > ok; then a third 'Requires:' should be added. But that's implicated by > 'Requires(...)' in the current tools. Note that after the %pre script of a package "bar" containing "Requires (pre): foo" has finished, as far as "bar" is concerned, "foo" can be erased, and rpm happily lets one do that. The effects of this in the current case at hand (dir ownership) is not really noticeable, but it may very well be in other cases, which is why it's best to stay away from depending on such side effects. Otherwise they _will_ eventually find their way into situations where it matters and bites. As a side note and a potential example case, it would make perfect sense to me if rpm would just bypass all Requires(foo) dependencies when a package is being installed, upgraded or erased with --noscripts. This is not the case today though. > > You are using side effects of tools not meant to enforce what you're > > trying to achieve. In other words, abusing them. What's wrong with > > plain Requires or PreReq? > > 'Requires:' does not guarantee that the directory exists when the package > is installed. How not? rpm does order normal dependencies too. Do you have an example where this would not hold for normal Requires (or PreReq within simple dependency loops using FC4's rpm)? See also below. > Semantic of 'PreReq' is not clear to me and afaik, it is > deprecated and should be replaced by 'Requires(...):'. Deprecated perhaps, but again, it's different from Requires(foo) and cannot be blindly just replaced like that everywhere. All this is documented in the max-rpm snapshot, here's the link again: http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html#S3-RPM-DEPEND-FINE-GRAINED If something's wrong in that section, please let me know. And note that I wrote this section before the PreReq magic was added back to FC4's rpm, that's why the slightly dubious tone regarding it. I believe it's still correct though. From katzj at redhat.com Tue May 24 16:03:06 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 24 May 2005 12:03:06 -0400 Subject: Packages failing rebuild for FE4 Message-ID: <1116950586.3439.93.camel@bree.local.net> I kicked off a number of Extras builds to try to sync up versions between architectures. A lot have succeeded, but some have failed. If you see a package you own in the list, if you could investigate the failure, it would be much appreciated. I've done some preliminary looking at the failures and tried to categorize them somewhat. I also started out looking at the existing bugs to see if there were patches that looked reasonable, but kind of gave up halfway through :) If you don't own any of the failed packages, feel free to pitch in and help out by attaching a patch to the bug and adding the Patch keyword.[1] If you need help with fixing any of them, join #fedora-devel and ask. People are around who have some experience in fixing problems of this sort. * csmash (http://extras64.linux.duke.edu/failed/development/csmash) Fails on x86_64, looks like a simple 64bit-ism. #156205 has a patch which looks like it should fix it * liboil (http://extras64.linux.duke.edu/failed/development/liboil/) Fails on i386 with broken asm. Filed as #158641 * cook (http://extras64.linux.duke.edu/failed/development/cook/) Fails on all arches due to broken code, #156203 has an indicator of how to fix * metakit (http://extras64.linux.duke.edu/failed/development/metakit/) Fails on x86_64, usual int/pointer confusion. #158460 * unison (http://extras64.linux.duke.edu/failed/development/unison/) Failed on ppc for no apparent reason. #158645 * scorched3d (http://extras64.linux.duke.edu/failed/development/scorched3d/) Failed on x86_64, usual int/pointer confusion. #158646 * viruskiller (http://extras64.linux.duke.edu/failed/development/viruskiller/) Failed on ppc for no apparent reason. #158647 * allegro (http://extras64.linux.duke.edu/failed/development/allegro/) Fails on all arches with invalid lvalues #158648 * arc (http://extras64.linux.duke.edu/failed/development/arc) Bad code, has a patch in #156225 * lincvs Missing buildrequires #156234 * libebml Fails on x86_64, int/pointer problems, #158649 * lablgtk Fails with invalid lvalue cast, #156230 has some patches * freedroidrpg Fails with invalid lvalue cast, #152498 has possible fix * qcad Fails on x86_64, int/pointer problem, #158650 * inkscape Fails on x86_64, int/pointer problem, #156228 has a possible fix * global Fails on all arches due to incorrect static function declartion, #156212 * gurlchecker Fails due to invalid lvalue cast, #156217 * screem Looks like it needs updating for the newer dbus, #153224 * libmatroska Fails on x86_64, int/pointer problem, #158651 * skencil Tries to build against python 2.3 instead of 2.4, #156245 * camstream Fails on ppc, #158652 * php-pecl-sqlite Looks like it needs to use sqlite2, not sqlite3, #156240. Maybe obsolete and should just be dropped? * netdiag Another of the random ppc failures, #158653 * seahorse And another, #156244 * amarok Needs to source qt.sh, #158654 * tla ppc again, #158655 * centericq Fails on x86_64, int/pointer #156202 * powermanga Fails on x86_64, int/pointer #158464 * celestica Fails on x86_64, int/pointer #158443 * Hermes Fails on i386 with mmx stuff, #156222 * psi Fails on x86_64, int/pointer, #158466 * gconfmm20 Fails on x86_64, int/pointer, #158448 Jeremy [1] Nominal arch maintainers can feel free to just fix the package and queue it for a build. From shahms at shahms.com Tue May 24 16:14:22 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 24 May 2005 09:14:22 -0700 Subject: Packages failing rebuild for FE4 In-Reply-To: <1116950586.3439.93.camel@bree.local.net> References: <1116950586.3439.93.camel@bree.local.net> Message-ID: <429352DE.3070107@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Katz wrote: | I kicked off a number of Extras builds to try to sync up versions | between architectures. A lot have succeeded, but some have failed. If | you see a package you own in the list, if you could investigate the | failure, it would be much appreciated. I've done some preliminary | looking at the failures and tried to categorize them somewhat. I also | started out looking at the existing bugs to see if there were patches | that looked reasonable, but kind of gave up halfway through :) Thank you for doing this Jeremy. One minor nit to pick is that some of these failed builds are impossible to debug and hence fix without more information than is present in the .failure.log file. The most information that file provides is: "the build failed, if you could access this local file, you might be able to figure out why. nya, nya, nya". Which, when you're trying to figure out why the build failed on an architecture to which you have no access, is more than useless and quite a bit frustrating. The 4.5M rpm log is, of course, present when the build succeeds. This seems, uh, backwards to me. Seth? Any chance you could change those build scripts to copy the rpm.log file when the build fails in addition to when it succeeds? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCk1Ld/qs2NkWy11sRAhE/AJ97dTD6Unk4fqfbptW/FEdK2+xqEwCdFIhk Y9j2X5ypfQoij45y7HIU8MY= =saSC -----END PGP SIGNATURE----- From katzj at redhat.com Tue May 24 17:19:33 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 24 May 2005 13:19:33 -0400 Subject: Packages failing rebuild for FE4 In-Reply-To: <429352DE.3070107@shahms.com> References: <1116950586.3439.93.camel@bree.local.net> <429352DE.3070107@shahms.com> Message-ID: <1116955173.3439.103.camel@bree.local.net> On Tue, 2005-05-24 at 09:14 -0700, Shahms King wrote: > Thank you for doing this Jeremy. One minor nit to pick is that some of > these failed builds are impossible to debug and hence fix without more > information than is present in the .failure.log file. The most > information that file provides is: "the build failed, if you could > access this local file, you might be able to figure out why. nya, nya, > nya". Which, when you're trying to figure out why the build failed on > an architecture to which you have no access, is more than useless and > quite a bit frustrating. The 4.5M rpm log is, of course, present when > the build succeeds. This seems, uh, backwards to me. Yeah, those are the ones that are harder... but most of the failures (luckily) don't fall into this category. So if we get the ones that are diagnosable, we'll be making good headway. > Seth? Any chance you could change those build scripts to copy the > rpm.log file when the build fails in addition to when it succeeds? >From looking at the code, it looks like that information should be getting written to the failed.log. Some of the ppc failures are absolutely bizarre, though. I'm working on setting up a machine locally to try to reproduce and figure out what's going on with some of them. Jeremy From dwmw2 at infradead.org Tue May 24 17:50:44 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 24 May 2005 18:50:44 +0100 Subject: Packages failing rebuild for FE4 In-Reply-To: <429352DE.3070107@shahms.com> References: <1116950586.3439.93.camel@bree.local.net> <429352DE.3070107@shahms.com> Message-ID: <1116957044.12012.514.camel@baythorne.infradead.org> On Tue, 2005-05-24 at 09:14 -0700, Shahms King wrote: > One minor nit to pick is that some of > these failed builds are impossible to debug and hence fix without more > information than is present in the .failure.log file. The most > information that file provides is: "the build failed, if you could > access this local file, you might be able to figure out why. nya, nya, > nya". Which, when you're trying to figure out why the build failed on > an architecture to which you have no access, is more than useless and > quite a bit frustrating. If you require access to a PPC machine running FC4, mail me a SSH public key. -- dwmw2 From shahms at shahms.com Tue May 24 17:38:50 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 24 May 2005 10:38:50 -0700 Subject: Packages failing rebuild for FE4 In-Reply-To: <1116955173.3439.103.camel@bree.local.net> References: <1116950586.3439.93.camel@bree.local.net> <429352DE.3070107@shahms.com> <1116955173.3439.103.camel@bree.local.net> Message-ID: <429366AA.8050900@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Katz wrote: |>From looking at the code, it looks like that information should be | getting written to the failed.log. Some of the ppc failures are | absolutely bizarre, though. I'm working on setting up a machine locally | to try to reproduce and figure out what's going on with some of them. | | Jeremy Thanks, I'd love to get tla building on PPC but it's a little difficult without a PPC machine to test on; any help is welcomed. I suspect I'll have to look into the differences between baz and tla where tla fails. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCk2aq/qs2NkWy11sRAj6EAJwK/6FFYE8RHQgEKHtweBKp1MqmZwCgzsf8 zYuMKr5nNkPW9kDQ0duWl2Y= =oXEF -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Tue May 24 18:18:22 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 24 May 2005 14:18:22 -0400 Subject: Packages failing rebuild for FE4 In-Reply-To: <1116957044.12012.514.camel@baythorne.infradead.org> References: <1116950586.3439.93.camel@bree.local.net> <429352DE.3070107@shahms.com> <1116957044.12012.514.camel@baythorne.infradead.org> Message-ID: <1116958702.14947.2.camel@ignacio.ignacio.lan> On Tue, 2005-05-24 at 18:50 +0100, David Woodhouse wrote: > On Tue, 2005-05-24 at 09:14 -0700, Shahms King wrote: > > One minor nit to pick is that some of > > these failed builds are impossible to debug and hence fix without more > > information than is present in the .failure.log file. The most > > information that file provides is: "the build failed, if you could > > access this local file, you might be able to figure out why. nya, nya, > > nya". Which, when you're trying to figure out why the build failed on > > an architecture to which you have no access, is more than useless and > > quite a bit frustrating. > > If you require access to a PPC machine running FC4, mail me a SSH public > key. Additionally I have a PPC machine sitting mostly idle. I can't give ssh access, but I am willing to test things if asked. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 katzj at redhat.com Tue May 24 20:29:24 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 24 May 2005 16:29:24 -0400 Subject: Removal of gtkmm20 (was Re: Packages failing rebuild for FE4) In-Reply-To: <4293855E.2080407@poolshark.org> References: <1116950586.3439.93.camel@bree.local.net> <4293855E.2080407@poolshark.org> Message-ID: <1116966564.3439.146.camel@bree.local.net> On Tue, 2005-05-24 at 12:49 -0700, Denis Leroy wrote: > Jeremy Katz wrote: > int/pointer, #158466 > > * gconfmm20 > > Fails on x86_64, int/pointer, #158448 > > I'd like to request comments on the proposal of removing all the gtkmm 2.0 API > packages from FC4 Extras : This seems reasonable to me.[1] If someone wishes to add an application later that requires one of these libraries, then they can go back to the packages we last had which worked and resurrect them. Place a request at http://fedoraproject.org/wiki/Extras_2fFC4Status and we'll make it happen. Jeremy [1] It does bring up that we should probably have a slightly more documented process on how to deprecate/remove packages. For now, I say we stick to "mail the list, see if anyone objects horribly" From jspaleta at gmail.com Tue May 24 22:04:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 24 May 2005 18:04:36 -0400 Subject: Removal of gtkmm20 (was Re: Packages failing rebuild for FE4) In-Reply-To: <1116966564.3439.146.camel@bree.local.net> References: <1116950586.3439.93.camel@bree.local.net> <4293855E.2080407@poolshark.org> <1116966564.3439.146.camel@bree.local.net> Message-ID: <604aa7910505241504302647e3@mail.gmail.com> On 5/24/05, Jeremy Katz wrote: > [1] It does bring up that we should probably have a slightly more > documented process on how to deprecate/remove packages. For now, I say > we stick to "mail the list, see if anyone objects horribly" And on a related note, how to notify users of extras that these packages have been dropped. Extras is somewhere between a rolling release and a point release model. I'm not sure a 'release notes' document like Core has/had detailing what has been removed since 'last release' makes sense as the primary notification tool for Extras. I doubt it's valid to assume that all package expirations from Extras will come at the opening of a new branch. Appropriate notification of package expiration is a tough nut. Ideally, it would be great if there was a way to inform all users relying on expired Extras packages that there will no longer be updates from this repository, through the same mechanisms as they get updates. But I don't see a way to do that within the current technical limitations of rpms without adding an additional peice of information at the repository level that kept a list of expired packagenames with timestamps for that repository. Package update tools could then parse that additional list of expired packages to notify users of expiration events. -jef From mattdm at mattdm.org Tue May 24 22:54:12 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 May 2005 18:54:12 -0400 Subject: The impending end of FC2 NEEDINFO bugs... Message-ID: <20050524225412.GA24363@jadzia.bu.edu> Just a heads-up: It's been almost month since I moved all open non-security FC2 bugs to NEEDINFO. Later this week, I plan to go the final step and move the ones that didn't get any action to DEFERRED. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From caillon at redhat.com Tue May 24 23:05:43 2005 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 24 May 2005 19:05:43 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050524225412.GA24363@jadzia.bu.edu> References: <20050524225412.GA24363@jadzia.bu.edu> Message-ID: <4293B347.40907@redhat.com> Matthew Miller wrote: > Just a heads-up: It's been almost month since I moved all open non-security > FC2 bugs to NEEDINFO. Later this week, I plan to go the final step and move > the ones that didn't get any action to DEFERRED. > Should the owners also change to a default fedora-legacy owner of some sort? I don't really plan on dealing with the FC2 bugs I own. From jkeating at j2solutions.net Tue May 24 23:25:25 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 24 May 2005 16:25:25 -0700 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <4293B347.40907@redhat.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> Message-ID: <1116977125.5703.2.camel@jkeating2.hq.pogolinux.com> On Tue, 2005-05-24 at 19:05 -0400, Christopher Aillon wrote: > Should the owners also change to a default fedora-legacy owner of > some > sort? I don't really plan on dealing with the FC2 bugs I own. If we get info and they are fixable sure, bugs at fedoralegacy.org. Otherwise closing them is enough. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From mattdm at mattdm.org Tue May 24 23:40:14 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 May 2005 19:40:14 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <1116977125.5703.2.camel@jkeating2.hq.pogolinux.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <1116977125.5703.2.camel@jkeating2.hq.pogolinux.com> Message-ID: <20050524234014.GA25882@jadzia.bu.edu> On Tue, May 24, 2005 at 04:25:25PM -0700, Jesse Keating wrote: > On Tue, 2005-05-24 at 19:05 -0400, Christopher Aillon wrote: > > Should the owners also change to a default fedora-legacy owner of > > some > > sort? I don't really plan on dealing with the FC2 bugs I own. > If we get info and they are fixable sure, bugs at fedoralegacy.org. > Otherwise closing them is enough. But only if they're security-related, right? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From mattdm at mattdm.org Tue May 24 23:43:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 May 2005 19:43:44 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <4293B347.40907@redhat.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> Message-ID: <20050524234344.GB25882@jadzia.bu.edu> On Tue, May 24, 2005 at 07:05:43PM -0400, Christopher Aillon wrote: > Should the owners also change to a default fedora-legacy owner of some > sort? I don't really plan on dealing with the FC2 bugs I own. Well, sort of the idea is that Fedora Legacy won't be either. bugzilla.redhat.com tells me that a resolution of deferred means "The problem described is a bug which will not be fixed in this version of the product." I think that should convey exactly what you just said. :) As before, I'll include a short message explaining what's going on. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From jkeating at j2solutions.net Tue May 24 23:54:07 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 24 May 2005 16:54:07 -0700 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050524234014.GA25882@jadzia.bu.edu> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <1116977125.5703.2.camel@jkeating2.hq.pogolinux.com> <20050524234014.GA25882@jadzia.bu.edu> Message-ID: <1116978847.5703.4.camel@jkeating2.hq.pogolinux.com> On Tue, 2005-05-24 at 19:40 -0400, Matthew Miller wrote: > > But only if they're security-related, right? Right. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From byte at aeon.com.my Wed May 25 00:09:55 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 25 May 2005 10:09:55 +1000 Subject: Packages failing rebuild for FE4 In-Reply-To: <429366AA.8050900@shahms.com> References: <1116950586.3439.93.camel@bree.local.net> <429352DE.3070107@shahms.com> <1116955173.3439.103.camel@bree.local.net> <429366AA.8050900@shahms.com> Message-ID: <1116979796.2773.105.camel@arena.soho.bytebot.net> On Tue, 2005-05-24 at 10:38 -0700, Shahms King wrote: > Thanks, I'd love to get tla building on PPC but it's a little > difficult > without a PPC machine to test on; any help is welcomed. I suspect > I'll > have to look into the differences between baz and tla where tla fails. Did the build log help you at all? I did add more to the bug report, and will take a gander at it today when I have a little more time (its a failure in a test, everything else is OK) -- Colin Charles, http://www.bytebot.net/ From shahms at shahms.com Wed May 25 00:19:45 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 24 May 2005 17:19:45 -0700 Subject: Packages failing rebuild for FE4 In-Reply-To: <1116979796.2773.105.camel@arena.soho.bytebot.net> References: <1116950586.3439.93.camel@bree.local.net> <429352DE.3070107@shahms.com> <1116955173.3439.103.camel@bree.local.net> <429366AA.8050900@shahms.com> <1116979796.2773.105.camel@arena.soho.bytebot.net> Message-ID: <4293C4A1.5000201@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Colin Charles wrote: | On Tue, 2005-05-24 at 10:38 -0700, Shahms King wrote: | |>Thanks, I'd love to get tla building on PPC but it's a little |>difficult |>without a PPC machine to test on; any help is welcomed. I suspect |>I'll |>have to look into the differences between baz and tla where tla fails. | | | Did the build log help you at all? I did add more to the bug report, and | will take a gander at it today when I have a little more time (its a | failure in a test, everything else is OK) Yeah, it gave me more information, I haven't had much time to look at it today (way too busy with work and school). It looks like the same place it was failing a little while ago, but I'll investigate further after I'm done with my schoolwork (possibly tonight, probably tomorrow). - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCk8Sg/qs2NkWy11sRAo09AJ0aCste7l9mvWedB0U71U3TBvqLcgCglpj6 mKiR1nAtTFHfPHCWFkV+aB8= =keuW -----END PGP SIGNATURE----- From wtogami at redhat.com Wed May 25 00:24:30 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 24 May 2005 14:24:30 -1000 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050524234344.GB25882@jadzia.bu.edu> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> Message-ID: <4293C5BE.1030008@redhat.com> Matthew Miller wrote: > On Tue, May 24, 2005 at 07:05:43PM -0400, Christopher Aillon wrote: > >>Should the owners also change to a default fedora-legacy owner of some >>sort? I don't really plan on dealing with the FC2 bugs I own. > > > Well, sort of the idea is that Fedora Legacy won't be either. > > bugzilla.redhat.com tells me that a resolution of deferred means "The > problem described is a bug which will not be fixed in this version of the > product." I think that should convey exactly what you just said. :) > > As before, I'll include a short message explaining what's going on. I don't think it should be DEFERRED but rather CURRENTRELEASE. DEFERRED implies that the bug intends to be revisited later, which is not the case. They were given a chance to change the bug from FC2 to a newer release and NEEDINFO status. If they haven't responded by now just assume it is fixed, and tell them about changing the Version and reopening if not. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Wed May 25 02:19:37 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 May 2005 22:19:37 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <1116978847.5703.4.camel@jkeating2.hq.pogolinux.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <1116977125.5703.2.camel@jkeating2.hq.pogolinux.com> <20050524234014.GA25882@jadzia.bu.edu> <1116978847.5703.4.camel@jkeating2.hq.pogolinux.com> Message-ID: <20050525021937.GA29828@jadzia.bu.edu> On Tue, May 24, 2005 at 04:54:07PM -0700, Jesse Keating wrote: > > But only if they're security-related, right? > Right. I've already gotten everything tagged as 'security', and my supposition is that while the severity field is often abused, it's moren likely to error in the other direction -- people flag their personal pet bugs as "critical", but hopefully won't mark remote security flaws as "minor".... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From mattdm at mattdm.org Wed May 25 02:26:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 May 2005 22:26:55 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <4293C5BE.1030008@redhat.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> Message-ID: <20050525022655.GB29828@jadzia.bu.edu> On Tue, May 24, 2005 at 02:24:30PM -1000, Warren Togami wrote: > I don't think it should be DEFERRED but rather CURRENTRELEASE. DEFERRED > implies that the bug intends to be revisited later, which is not the > case. They were given a chance to change the bug from FC2 to a newer > release and NEEDINFO status. If they haven't responded by now just > assume it is fixed, and tell them about changing the Version and > reopening if not. Many of these *aren't* fixed in the current release, though. They're feature requests that were rejected or ignored, non-reproducable one-time-glitches, various misunderstandings of the way things work, and yep, actual bugs that got dropped on the floor and aren't going to get addressed in reality. I think DEFERRED is the best option (given the description in bugzilla) given the mix of bugs -- many of them *are* actually gonna be real issues. The other alternative that makes sense is WONTFIX. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From wtogami at redhat.com Wed May 25 02:30:31 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 24 May 2005 16:30:31 -1000 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050525022655.GB29828@jadzia.bu.edu> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> Message-ID: <4293E347.2020309@redhat.com> Matthew Miller wrote: > On Tue, May 24, 2005 at 02:24:30PM -1000, Warren Togami wrote: > >>I don't think it should be DEFERRED but rather CURRENTRELEASE. DEFERRED >>implies that the bug intends to be revisited later, which is not the >>case. They were given a chance to change the bug from FC2 to a newer >>release and NEEDINFO status. If they haven't responded by now just >>assume it is fixed, and tell them about changing the Version and >>reopening if not. > > > Many of these *aren't* fixed in the current release, though. They're feature > requests that were rejected or ignored, non-reproducable one-time-glitches, > various misunderstandings of the way things work, and yep, actual bugs that > got dropped on the floor and aren't going to get addressed in reality. > > I think DEFERRED is the best option (given the description in bugzilla) > given the mix of bugs -- many of them *are* actually gonna be real issues. > > The other alternative that makes sense is WONTFIX. WONTFIX is more truthful then. DEFERRED is a really bad and confusing state IMHO. Could you post a draft of the accompanying closing message here before doing so? Warren Togami wtogami at redhat.com From mattdm at mattdm.org Wed May 25 03:04:18 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 24 May 2005 23:04:18 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <4293E347.2020309@redhat.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> Message-ID: <20050525030418.GA31087@jadzia.bu.edu> On Tue, May 24, 2005 at 04:30:31PM -1000, Warren Togami wrote: > WONTFIX is more truthful then. DEFERRED is a really bad and confusing > state IMHO. Could you post a draft of the accompanying closing message > here before doing so? WONTFIX just sounded so harsh. BUt yeah, I'll definitely post a draft message, and as before I'll make sure I'm on the CC list of all of the bugs so I can deal with any resulting messes. Not that I anticipate any this time around -- the whole experiment has gone pretty well, as we're down to about 500 NEEDINFO bugs, from over 1000 open bugs before. (Unfortunately I didn't count how many were already in NEEDINFO state.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From mharris at www.linux.org.uk Wed May 25 07:11:03 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 25 May 2005 03:11:03 -0400 Subject: Stricter rpmbuild with unpackaged files In-Reply-To: <1116860524.16089.1.camel@enki.eridu> References: <1116860524.16089.1.camel@enki.eridu> Message-ID: <42942507.40807@www.linux.org.uk> Paul Nasrat wrote: > The unpackaged files checks now catch unpackaged symlinks. As per FC4 > tracker request > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108778 Great work. This caught a bug in xorg-x11 packaging that's been there forever. The libFS.so and libGLw.so libs were previously static only, and when the shared versions were added in 6.7.0, the .so links were inadvertently left from the file list and nobody ever noticed. ;o) Of course apps using these libs would have just fallen back to the static libs instead, so minor problem overall, but nice to know such issues will be detected automatically by rpm in the future. Thanks. From mharris at www.linux.org.uk Wed May 25 07:23:04 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 25 May 2005 03:23:04 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050524225412.GA24363@jadzia.bu.edu> References: <20050524225412.GA24363@jadzia.bu.edu> Message-ID: <429427D8.20609@www.linux.org.uk> Matthew Miller wrote: > Just a heads-up: It's been almost month since I moved all open non-security > FC2 bugs to NEEDINFO. Later this week, I plan to go the final step and move > the ones that didn't get any action to DEFERRED. I think I've already covered all bugs FC-2 or older for xorg-x11 and other packages I maintain. In general I think "WONTFIX" or some other resolution is preferred. The X team is avoiding using the "DEFERRED" resolution completely nowadays because it is essentially a permanent procrastination device that smells of indecision. I think if something is to be truly "deferred" and have it not mean "procrastinate" or "never", it has to have a solid decision made about it, which either includes a final resolution (WONTFIX/NOTABUG/ UPSTREAM/NEXTRELEASE/CURRENTRELEASE, etc) or if it is thought to still be an issue, it should be a signed a definite "target" to which it will be investigated/reviewed/fixed/etc. Targets can be OS release milestones or update milestones, and are tracked in bugzilla by target trackers. For example, in the past I would have marked a bug that would be deferred for a future release as "DEFERRED", however over time that just made a big pileup of bugs in "DEFERRED" state which mostly never got attention again, although some did. By avoiding "DEFERRED" and using target trackers, the attention shifts from "we're not going to do this right now" (with no decision made as to when it will be done) shifts to "we will look at this for FC5, by adding it to the FC5Target tracker". The latter ensures it is definitely on radar, and IMHO seems more decisive to me. We can always later on decide it to be an FC6Target if desired, or we could later decide to change our minds and close it WONTFIX or something else depending on circumstances at the time in the future. Anyhow, I just thought I'd offer this as a potential alternative suggestion to consider. I've been using this strategy for many months now and find it really helps with bug management, and keeps the "future TODO" procrastination lists significantly shorter, simply by forcing more solid decisions to be made. Hope the idea is useful to others too. Take care, TTYL From mharris at www.linux.org.uk Wed May 25 07:38:36 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Wed, 25 May 2005 03:38:36 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050525030418.GA31087@jadzia.bu.edu> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> Message-ID: <42942B7C.4010605@www.linux.org.uk> Matthew Miller wrote: > On Tue, May 24, 2005 at 04:30:31PM -1000, Warren Togami wrote: > >>WONTFIX is more truthful then. DEFERRED is a really bad and confusing >>state IMHO. Could you post a draft of the accompanying closing message >>here before doing so? > > > WONTFIX just sounded so harsh. BUt yeah, I'll definitely post a draft > message, and as before I'll make sure I'm on the CC list of all of the bugs > so I can deal with any resulting messes. Not that I anticipate any this time > around -- the whole experiment has gone pretty well, as we're down to about > 500 NEEDINFO bugs, from over 1000 open bugs before. (Unfortunately I didn't > count how many were already in NEEDINFO state.) I agree. The negative bug resolution states, etc. are really just that - negative/reactive rather than positive/proactive. When someone doesn't respond, I have a preference for using, CURRENTRELEASE, RAWHIDE, NEXTRELEASE, or ERRATA resolutions using a comment of the nature: "The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there haven't been any updates to the report in quite a long time now after we've requested additional information, we're assuming the problem is either no longer present in our current OS release, or that there is no longer any interest in tracking the problem. Setting status to "CURRENTRELEASE", however if you still experience this problem after updating to our latest Fedora Core release and are still interested in Red Hat tracking the issue, and assisting in troubleshooting the problem, please feel free to provide the information requested above, and reopen the report. Thanks in advance." This sends people a much more friendly message than does "WONTFIX" and it's ilk, but is essentially the same bottom line really: "If you don't respond to our requests for more info, and we need more info, then we're not going to track the problem indefinitely because there's nothing we can do about it." - only it takes all of those negative words out, and instead of telling what we wont do and why not, it tells what we WILL do, HOW, and under what CONDITIONS and EXPECTATIONS. It lets people know the bottom line in a generally much friendlier way. The results I have gotten by using proactive friendly messages of this nature in the last year, have been very very good. Generally the responses fit into the following categories: 1) Person finally provides the info and reopens the report, usually apologizing for being busy or something similar. 2) Person finally reports the issue to upstream as we've requested and provides the URL to us for tracking (assuming we've requested them to do this and are waiting for the URL). 3) Person indicates they no longer have the computer the problem occured on, or no longer have an interest in the bug for whatever particular reason. 4) Person indicates the problem no longer exists in a newer OS release and closes it, or tells us we can do so. 5) Person never responds back, indicating they're fine with this resolution, or perhaps their email address doesn't exist anymore or something. 6) Person complains. In general, response #5 (no response) is by far the most common. #4 is next most common, followed by #1 and #2, then #3. The best part is that #6 almost *never* happens, which is fantastic because: 1) Who actually likes to hear people complain? 2) Who actually enjoys complaining or feeling the need to do so? In general, this approach has worked fantastic, and has helped greatly to narrow the bug list down from 600 to its current approximate total of 75 or so for X. Thoughts/feedback about this approach appreciated. Take care, TTYL From mitr at redhat.com Wed May 25 08:48:41 2005 From: mitr at redhat.com (Miloslav Trmac) Date: Wed, 25 May 2005 10:48:41 +0200 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42942B7C.4010605@www.linux.org.uk> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> Message-ID: <20050525084841.GA4834@amilo> On Wed, May 25, 2005 at 03:38:36AM -0400, Mike A. Harris wrote: > When someone doesn't respond, I have a preference for using, > CURRENTRELEASE, RAWHIDE, NEXTRELEASE, or ERRATA resolutions > using a comment of the nature: > > "The information we've requested above is required in order > to review this problem report further and diagnose/fix the > issue if it is still present. Since there haven't been any > updates to the report in quite a long time now after we've > requested additional information, we're assuming the problem > is either no longer present in our current OS release, or > that there is no longer any interest in tracking the problem. > > Setting status to "CURRENTRELEASE", however if you still > experience this problem after updating to our latest Fedora > Core release and are still interested in Red Hat tracking > the issue, and assisting in troubleshooting the problem, > please feel free to provide the information requested above, > and reopen the report. This is also abusing the bugzilla resolution status; if somebody looks for a bug he is experiencing and finds it, he sees "CURRENTRELEASE" when in fact it is "WE-WISH-IT-WERE-CURRENTRELEASE". NOTABUG nor WONTFIX is perfect, but either provides more correct information than CURRENTRELEASE. Mirek From tgl at redhat.com Wed May 25 13:44:12 2005 From: tgl at redhat.com (Tom Lane) Date: Wed, 25 May 2005 09:44:12 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050525084841.GA4834@amilo> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> Message-ID: <11601.1117028652@sss.pgh.pa.us> Miloslav Trmac writes: > On Wed, May 25, 2005 at 03:38:36AM -0400, Mike A. Harris wrote: >> Setting status to "CURRENTRELEASE", however if you still >> experience this problem after updating to our latest Fedora >> Core release and are still interested in Red Hat tracking >> the issue, and assisting in troubleshooting the problem, >> please feel free to provide the information requested above, >> and reopen the report. > This is also abusing the bugzilla resolution status; if somebody > looks for a bug he is experiencing and finds it, he sees > "CURRENTRELEASE" when in fact it is "WE-WISH-IT-WERE-CURRENTRELEASE". > NOTABUG nor WONTFIX is perfect, but either provides more correct > information than CURRENTRELEASE. Is there a reason not to leave such bugs in NEEDINFO state forever? regards, tom lane From dmalcolm at redhat.com Wed May 25 15:57:47 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 25 May 2005 11:57:47 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42942B7C.4010605@www.linux.org.uk> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> Message-ID: <1117036668.24337.3.camel@cassandra.boston.redhat.com> On Wed, 2005-05-25 at 03:38 -0400, Mike A. Harris wrote: [snip] > When someone doesn't respond, I have a preference for using, > CURRENTRELEASE, RAWHIDE, NEXTRELEASE, or ERRATA resolutions > using a comment of the nature: > > > "The information we've requested above is required in order > to review this problem report further and diagnose/fix the > issue if it is still present. Since there haven't been any > updates to the report in quite a long time now after we've > requested additional information, we're assuming the problem > is either no longer present in our current OS release, or > that there is no longer any interest in tracking the problem. > > Setting status to "CURRENTRELEASE", however if you still > experience this problem after updating to our latest Fedora > Core release and are still interested in Red Hat tracking > the issue, and assisting in troubleshooting the problem, > please feel free to provide the information requested above, > and reopen the report. > > Thanks in advance." > I went ahead and added the above text to this wiki page: http://fedoraproject.org/wiki/StockBugzillaResponses If anyone's got ideas for further improvements to that page, they'd be most welcome. [snip] From jspaleta at gmail.com Wed May 25 16:04:57 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 25 May 2005 12:04:57 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050525084841.GA4834@amilo> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> Message-ID: <604aa79105052509045957fa84@mail.gmail.com> On 5/25/05, Miloslav Trmac wrote: > This is also abusing the bugzilla resolution status; if somebody > looks for a bug he is experiencing and finds it, he sees > "CURRENTRELEASE" when in fact it is "WE-WISH-IT-WERE-CURRENTRELEASE". > NOTABUG nor WONTFIX is perfect, but either provides more correct > information than CURRENTRELEASE. Mike has a very valid point though, perhaps the value of technically precise categorization is not as valuable as sloppier categorization that promotes a skewed happy-happy joy-joy perception and encourages a 'work with us' attitude. Is the bugzilla database aiming to be a historical statitician's research treasure trove, or a medium by which developers and users attempt to communicate day-to-day, week-to-week? I've seen too many users blow a fuse at seeing wontfix or notabug as a resolution to something they filed, souring them to the bug filing experience because they come away with a perception that their issue is being completely ignored. Talking these potentially valuable contributors down from the ledge has become far less thrilling an experience over time. Instead of continually tying to fix novice, psychologically fragile perceptions of malicious intent of certain bug resolution states. it might be more effective to simply lie about the resolution state to encourage flow of information. The terse language of the finite resolution namespace can be a bit harsh. If I ruled the world, I'd probably forcible dictate the creation of "RETEST" as a companion to "RESOLVED", so I could have "RETEST" "CURRENTRELEASE" for many of the situations Mike has described. legacy of course complicates the issue for security issues legacy claims interest in. -jef"'The Whiz Man' will never fit like 'The Whiz Kid' did"spaleta From wtogami at redhat.com Wed May 25 20:02:06 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 25 May 2005 10:02:06 -1000 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <604aa79105052509045957fa84@mail.gmail.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> Message-ID: <4294D9BE.7090305@redhat.com> Jeff Spaleta wrote: > > I've seen too many users blow a fuse at seeing wontfix or notabug as a > resolution to something they filed, souring them to the bug filing > experience because they come away with a perception that their issue This can be mostly mitigated with the right paragraph included along with the WONTFIX. Don't worry. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Wed May 25 20:15:57 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 25 May 2005 16:15:57 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <4294D9BE.7090305@redhat.com> References: <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4294D9BE.7090305@redhat.com> Message-ID: <20050525201557.GA1733@jadzia.bu.edu> On Wed, May 25, 2005 at 10:02:06AM -1000, Warren Togami wrote: > This can be mostly mitigated with the right paragraph included along > with the WONTFIX. Don't worry. Have been very busy today. I'll post said draft paragraph RSN. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From skvidal at phy.duke.edu Thu May 26 03:28:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 25 May 2005 23:28:35 -0400 Subject: Packages failing rebuild for FE4 In-Reply-To: <429352DE.3070107@shahms.com> References: <1116950586.3439.93.camel@bree.local.net> <429352DE.3070107@shahms.com> Message-ID: <1117078115.3347.0.camel@cutter> > Thank you for doing this Jeremy. One minor nit to pick is that some of > these failed builds are impossible to debug and hence fix without more > information than is present in the .failure.log file. The most > information that file provides is: "the build failed, if you could > access this local file, you might be able to figure out why. nya, nya, > nya". Which, when you're trying to figure out why the build failed on > an architecture to which you have no access, is more than useless and > quite a bit frustrating. The 4.5M rpm log is, of course, present when > the build succeeds. This seems, uh, backwards to me. > > Seth? Any chance you could change those build scripts to copy the > rpm.log file when the build fails in addition to when it succeeds? The logging problem has been taken care of in mock. Mach currently still does some odd things with saving logs where one might expect them to be. -sv From wtogami at redhat.com Thu May 26 05:51:15 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 25 May 2005 19:51:15 -1000 Subject: Requires(post,postun) Message-ID: <429563D3.6020702@redhat.com> Requires(post,postun) Is this syntax still a problem in latest FC4? Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu May 26 06:07:59 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 25 May 2005 20:07:59 -1000 Subject: fedora-rpmdevtools CVS move Message-ID: <429567BF.9040206@redhat.com> http://cvs.fedora.us/cgi-bin/cvsweb.cgi/pkg/fedora-rpmdevtools/ Anyone object if we move this CVS to cvs.fedora.redhat.com:/cvs/fedora? I might be losing the server hosting at the University soon so I need to begin moving everything now. Is it possible to move the entire CVS module including change info? If so how? Warren Togami wtogami at redhat.com From ivazquez at ivazquez.net Thu May 26 07:06:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 26 May 2005 03:06:38 -0400 Subject: fedora-rpmdevtools CVS move In-Reply-To: <429567BF.9040206@redhat.com> References: <429567BF.9040206@redhat.com> Message-ID: <1117091198.30966.50.camel@ignacio.ignacio.lan> On Wed, 2005-05-25 at 20:07 -1000, Warren Togami wrote: > http://cvs.fedora.us/cgi-bin/cvsweb.cgi/pkg/fedora-rpmdevtools/ > > Anyone object if we move this CVS to cvs.fedora.redhat.com:/cvs/fedora? > I might be losing the server hosting at the University soon so I need > to begin moving everything now. > > Is it possible to move the entire CVS module including change info? If > so how? IIRC copying the module itself from the repo on-disk should preserve everything. Deal with the contents of CVSROOT as you like. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mharris at www.linux.org.uk Thu May 26 14:56:24 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 26 May 2005 10:56:24 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <11601.1117028652@sss.pgh.pa.us> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> Message-ID: <4295E398.2050502@www.linux.org.uk> Tom Lane wrote: > Miloslav Trmac writes: > >>On Wed, May 25, 2005 at 03:38:36AM -0400, Mike A. Harris wrote: >> >>>Setting status to "CURRENTRELEASE", however if you still >>>experience this problem after updating to our latest Fedora >>>Core release and are still interested in Red Hat tracking >>>the issue, and assisting in troubleshooting the problem, >>>please feel free to provide the information requested above, >>>and reopen the report. > > >>This is also abusing the bugzilla resolution status; if somebody >>looks for a bug he is experiencing and finds it, he sees >>"CURRENTRELEASE" when in fact it is "WE-WISH-IT-WERE-CURRENTRELEASE". >>NOTABUG nor WONTFIX is perfect, but either provides more correct >>information than CURRENTRELEASE. > > > Is there a reason not to leave such bugs in NEEDINFO state forever? Yes. Then there are 100000 bugs open forever, that will never be addressed. From mharris at www.linux.org.uk Thu May 26 15:02:58 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 26 May 2005 11:02:58 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <604aa79105052509045957fa84@mail.gmail.com> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> Message-ID: <4295E522.7060406@www.linux.org.uk> Jeff Spaleta wrote: > On 5/25/05, Miloslav Trmac wrote: > >>This is also abusing the bugzilla resolution status; if somebody >>looks for a bug he is experiencing and finds it, he sees >>"CURRENTRELEASE" when in fact it is "WE-WISH-IT-WERE-CURRENTRELEASE". >>NOTABUG nor WONTFIX is perfect, but either provides more correct >>information than CURRENTRELEASE. > > > Mike has a very valid point though, perhaps the value of technically > precise categorization is not as valuable as sloppier categorization > that promotes a skewed happy-happy joy-joy perception and encourages a > 'work with us' attitude. Is the bugzilla database aiming to be a > historical statitician's research treasure trove, or a medium by which > developers and users attempt to communicate day-to-day, week-to-week? > > I've seen too many users blow a fuse at seeing wontfix or notabug as a > resolution to something they filed, souring them to the bug filing > experience because they come away with a perception that their issue > is being completely ignored. Talking these potentially valuable > contributors down from the ledge has become far less thrilling an > experience over time. Instead of continually tying to fix novice, > psychologically fragile perceptions of malicious intent of certain bug > resolution states. it might be more effective to simply lie about the > resolution state to encourage flow of information. The terse > language of the finite resolution namespace can be a bit harsh. If I > ruled the world, I'd probably forcible dictate the creation of > "RETEST" as a companion to "RESOLVED", so I could have "RETEST" > "CURRENTRELEASE" for many of the situations Mike has described. legacy > of course complicates the issue for security issues legacy claims > interest in. This very much hits the nail on the head. When using the bugzilla resolutions as documented in bugzilla, what I have learned is that people often get very upset. Nobody likes to be told "no", "go away", WONTFIX, NOTABUG, etc. Negative resolutions are just plain BAD. Some might call it pedantic word games, but the fact is that it is all about providing a positive user/customer experience, and by utilizing positive and proactive language, the same results can be achieved as telling someone "NOTABUG" or "WONTFIX" without coming off as rude or obnoxious, simply by preferring the more positive sounding resolutions, with a polite comment. Bugzilla really needs a "proactivity" facelift. I used to use bugzilla's stock resolutions and the negative responses from people really got to me. It was hard NOT to take rude comments personally, and respond as such. That was not a particularly enjoyable or useful experience. The new approach is much more successful at reaching the goals set forth by our subteam, and is also much appreciated by our customers and users. By following this approach, I rarely ever see negative comments in bugzilla anymore after updating a bug and/or closing it. So, it works very well for me at least, and I hope others find it useful too. From mharris at www.linux.org.uk Thu May 26 15:04:01 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 26 May 2005 11:04:01 -0400 Subject: Requires(post,postun) In-Reply-To: <429563D3.6020702@redhat.com> References: <429563D3.6020702@redhat.com> Message-ID: <4295E561.2090007@www.linux.org.uk> Warren Togami wrote: > Requires(post,postun) > > Is this syntax still a problem in latest FC4? It was fixed a while ago. It only works for install/upgrade though, aparently rpm does not respect it on uninstall. From tgl at redhat.com Thu May 26 15:08:33 2005 From: tgl at redhat.com (Tom Lane) Date: Thu, 26 May 2005 11:08:33 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <4295E398.2050502@www.linux.org.uk> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> Message-ID: <2402.1117120113@sss.pgh.pa.us> "Mike A. Harris" writes: > Tom Lane wrote: >> Is there a reason not to leave such bugs in NEEDINFO state forever? > Yes. Then there are 100000 bugs open forever, that will never > be addressed. Fair enough. What about adding a resolution category "closed for lack of information", which we could use if something stays in NEEDINFO too long? Or I suppose we could use WORKSFORME ... regards, tom lane From mharris at www.linux.org.uk Thu May 26 15:41:01 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 26 May 2005 11:41:01 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <2402.1117120113@sss.pgh.pa.us> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> Message-ID: <4295EE0D.8070106@www.linux.org.uk> Tom Lane wrote: > "Mike A. Harris" writes: > >>Tom Lane wrote: >> >>>Is there a reason not to leave such bugs in NEEDINFO state forever? > > >>Yes. Then there are 100000 bugs open forever, that will never >>be addressed. > > > Fair enough. What about adding a resolution category "closed for lack > of information", which we could use if something stays in NEEDINFO > too long? Or I suppose we could use WORKSFORME ... Still sounds like a negative response to me. Any negative statements should be inverted and made positive. CLOSED->REQUIRES_MORE_INFORMATION Semantically similar to "NEEDINFO", but this one is essentially "CLOSED->NEEDINFO" rather than OPEN_STILL->NEEDINFO, so different. Another one could be: CLOSED->REQUIRES_RESPONSE And another useful one would be: CLOSED->EXTERNAL_ISSUE (for things that might indeed be bugs, but are not OUR bug. Various bugzillas have a NOTOURBUG resolution for this, but that is negative/reactive, whereas EXTERNAL_ISSUE is pointing out what the problem is, rather than what it isn't.) From bugs.michael at gmx.net Thu May 26 15:43:11 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 May 2005 17:43:11 +0200 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <2402.1117120113@sss.pgh.pa.us> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> Message-ID: <20050526174311.1aa3c48d.bugs.michael@gmx.net> On Thu, 26 May 2005 11:08:33 -0400, Tom Lane wrote: > "Mike A. Harris" writes: > > Tom Lane wrote: > >> Is there a reason not to leave such bugs in NEEDINFO state forever? > > > Yes. Then there are 100000 bugs open forever, that will never > > be addressed. > > Fair enough. What about adding a resolution category "closed for lack > of information", which we could use if something stays in NEEDINFO > too long? Or I suppose we could use WORKSFORME ... NEEDINFO -> no reply -> WONTFIX : that really is the most true resolution. Without feedback, the bug won't be fixed because it won't be examined further. Just explain that when closing the ticket. Keep in mind that the reporter can reopen the ticket as soon as new feedback is provided. From alan at redhat.com Thu May 26 15:52:09 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 26 May 2005 11:52:09 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <2402.1117120113@sss.pgh.pa.us> References: <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> Message-ID: <20050526155209.GC20612@devserv.devel.redhat.com> On Thu, May 26, 2005 at 11:08:33AM -0400, Tom Lane wrote: > Fair enough. What about adding a resolution category "closed for lack > of information", which we could use if something stays in NEEDINFO > too long? Or I suppose we could use WORKSFORME ... Why close them - some day someone may recognize the similarity between a few bugs in review, or a user may hit the same bug and have the needed information. A new state indicating "we don't plan to do anything with this bug but the report is worth keeping" might be useful for making search easier but don't lose the data. From kaboom at oobleck.net Thu May 26 15:54:57 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 26 May 2005 11:54:57 -0400 (EDT) Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050526155209.GC20612@devserv.devel.redhat.com> References: <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526155209.GC20612@devserv.devel.redhat.com> Message-ID: On Thu, 26 May 2005, Alan Cox wrote: > On Thu, May 26, 2005 at 11:08:33AM -0400, Tom Lane wrote: > > Fair enough. What about adding a resolution category "closed for lack > > of information", which we could use if something stays in NEEDINFO > > too long? Or I suppose we could use WORKSFORME ... > > Why close them - some day someone may recognize the similarity between a few > bugs in review, or a user may hit the same bug and have the needed information. > > A new state indicating "we don't plan to do anything with this bug but the > report is worth keeping" might be useful for making search easier but don't > lose the data. How does closing a ticket lose any data? The report's still in the database.... later, chris From alan at redhat.com Thu May 26 15:58:38 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 26 May 2005 11:58:38 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: References: <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526155209.GC20612@devserv.devel.redhat.com> Message-ID: <20050526155838.GF20612@devserv.devel.redhat.com> On Thu, May 26, 2005 at 11:54:57AM -0400, Chris Ricker wrote: > > report is worth keeping" might be useful for making search easier but don't > > lose the data. > > How does closing a ticket lose any data? The report's still in the > database.... Closed is perhaps the wrong phrase. It wants to stay in the database in a state that doesn't imply "tough we don't care" which WONTFIX does imply. As has been suggested a CLOSED/NEEDINFO would have the right meaning From fche at redhat.com Thu May 26 15:59:00 2005 From: fche at redhat.com (Frank Ch. Eigler) Date: Thu, 26 May 2005 11:59:00 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050526155209.GC20612@devserv.devel.redhat.com> References: <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526155209.GC20612@devserv.devel.redhat.com> Message-ID: <20050526155859.GD9705@redhat.com> Hi - On Thu, May 26, 2005 at 11:52:09AM -0400, Alan Cox wrote: > > Fair enough. What about adding a resolution category "closed for lack > > of information", which we could use if something stays in NEEDINFO > > too long? Or I suppose we could use WORKSFORME ... > Why close them - some day someone may recognize the similarity > between a few bugs in review, or a user may hit the same bug and > have the needed information. Closed bugs may still be located using keyword searches. If they are any more prominent than that, then there is little point even pseudo-closing them. > A new state indicating "we don't plan to do anything with this bug > but the report is worth keeping" might be useful for making search > easier but don't lose the data. The NEEDINFO state seems adequate for this, as does CLOSED/DEFERRED. - FChE -------------- 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 Thu May 26 15:59:21 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 26 May 2005 11:59:21 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <4295E522.7060406@www.linux.org.uk> References: <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> Message-ID: <20050526155921.GA1841@jadzia.bu.edu> On Thu, May 26, 2005 at 11:02:58AM -0400, Mike A. Harris wrote: > Negative resolutions are just plain BAD. Some might call it > pedantic word games, but the fact is that it is all about providing > a positive user/customer experience, and by utilizing positive and > proactive language, the same results can be achieved as telling > someone "NOTABUG" or "WONTFIX" without coming off as rude or > obnoxious, simply by preferring the more positive sounding > resolutions, with a polite comment. Mike, I see where you're coming from, but I think this needs to be backed up with actual resources from Red Hat to help maintain Fedora Legacy. It's not good for the long term to provide a *falsely* positive experience -- currently, the explicit *plan* from Red Hat / Fedora is that bugs in older releases will be ignored, and it seems more honest to tell people WONTFIX even if that makes them upset -- unless there actually *will* be resources for dealing with the problem. I *do* really appreciate everyone from RH (and everywhere else) who has helped go through the open FC2 bugs and resolve them one way or another -- that's been very positive and good. More later. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 72 degrees Fahrenheit. From ville.skytta at iki.fi Thu May 26 16:24:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 26 May 2005 19:24:30 +0300 Subject: fedora-rpmdevtools CVS move In-Reply-To: <1117091198.30966.50.camel@ignacio.ignacio.lan> References: <429567BF.9040206@redhat.com> <1117091198.30966.50.camel@ignacio.ignacio.lan> Message-ID: <1117124670.22702.14.camel@bobcat.mine.nu> On Thu, 2005-05-26 at 03:06 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-05-25 at 20:07 -1000, Warren Togami wrote: > > http://cvs.fedora.us/cgi-bin/cvsweb.cgi/pkg/fedora-rpmdevtools/ > > > > Anyone object if we move this CVS to cvs.fedora.redhat.com:/cvs/fedora? > > I might be losing the server hosting at the University soon so I need > > to begin moving everything now. > > > > Is it possible to move the entire CVS module including change info? If > > so how? > > IIRC copying the module itself from the repo on-disk should preserve > everything. Ditto. > Deal with the contents of CVSROOT as you like. I don't think there's need to do that in this case. From jspaleta at gmail.com Thu May 26 16:40:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 26 May 2005 12:40:13 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050526155921.GA1841@jadzia.bu.edu> References: <4293B347.40907@redhat.com> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> Message-ID: <604aa79105052609406d7c8278@mail.gmail.com> On 5/26/05, Matthew Miller wrote: > Mike, I see where you're coming from, but I think this needs to be backed up > with actual resources from Red Hat to help maintain Fedora Legacy. It's not > good for the long term to provide a *falsely* positive experience -- > currently, the explicit *plan* from Red Hat / Fedora is that bugs in older > releases will be ignored, and it seems more honest to tell people WONTFIX > even if that makes them upset -- unless there actually *will* be resources > for dealing with the problem. Sure.. bugs that only affect the older core release.. will be ignored. No one is arguing that they wont. What Mike is saying, is there needs to be a way to positivitly encourage people who were experiencing problems with older releases and lost touch to upgrade and see if the problem is taken care of in the current release. Its a matter of perception and priority..is it more important to tailor response to the release under which the bug was filed.. or is it more appropriate to see if the problem still exists with the current software? I'm pretty confident many Core maintainers would love for people experiencing weird issues to upgraded to the current release (maybe even rawhide), re-test and report back. Legacy maintainers of course have a different desire. There is a difference between ignoring a bug filed against fc2 because fc2 is legacy and ignoring the reported problems completely. You don't want to give novice users the false perception that that developers aren't interested in fixing the underlying problems at all..in any release..ever. Unfortunately that is exactly what happens to many users.. they assume wontfix means 'wontfix ever in any release from now till the end of time.' Users need to be gently guided to an understanding that the primary focus for developers is the development tree and secondarily the current release of core. Asking people to upgrade to the current release and retest prevents users from assuming the developers are totally uninterested in the problem. The WONTFIX state screams to some users 'this issue is a waste of my precious developer time i do not care about this issue and i never will care about this issue so don't bother refiling it again even if you do upgrade to the next core and still see the problem.' It's not rational behavior. Then again I would argue most 'novice enthusiasts' that make up a large chunk of the incoming fedora userbase every release..are inherently irrational and maybe we houldn't expect them to be otherwise. We can't snap our fingers and make people behave rationally(not till we have federally mandated neural implants), but we can do a little bit of social engineering to make bugzilla work more efficiently as a communication medium. -jef From mharris at www.linux.org.uk Thu May 26 17:41:35 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 26 May 2005 13:41:35 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050526174311.1aa3c48d.bugs.michael@gmx.net> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> Message-ID: <42960A4F.3080502@www.linux.org.uk> Michael Schwendt wrote: > On Thu, 26 May 2005 11:08:33 -0400, Tom Lane wrote: > > >>"Mike A. Harris" writes: >> >>>Tom Lane wrote: >>> >>>>Is there a reason not to leave such bugs in NEEDINFO state forever? >> >>>Yes. Then there are 100000 bugs open forever, that will never >>>be addressed. >> >>Fair enough. What about adding a resolution category "closed for lack >>of information", which we could use if something stays in NEEDINFO >>too long? Or I suppose we could use WORKSFORME ... > > > NEEDINFO -> no reply -> WONTFIX : that really is the most true > resolution. Without feedback, the bug won't be fixed because it won't be > examined further. Just explain that when closing the ticket. Keep in mind > that the reporter can reopen the ticket as soon as new feedback is > provided. I disagree. There are different ways to say the same thing, and while "WONTFIX" is very much true, it is NOT the best way of saying it. Or should I say instead - There are better ways of saying "WONTFIX" that are more positive and friendly. One could argue GO_TO_HELL is a "true" resolution for some bugs, but is it "friendly"? Is it "proactive"? Does it give the reporter a warm feeling in their stomach? No. From gdk at redhat.com Thu May 26 17:45:16 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Thu, 26 May 2005 13:45:16 -0400 (EDT) Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42960A4F.3080502@www.linux.org.uk> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <42960A4F.3080502@www.linux.org.uk> Message-ID: On Thu, 26 May 2005, Mike A. Harris wrote: > I disagree. There are different ways to say the same thing, and > while "WONTFIX" is very much true, it is NOT the best way of saying > it. Or should I say instead - There are better ways of saying > "WONTFIX" that are more positive and friendly. > > One could argue GO_TO_HELL is a "true" resolution for some bugs, > but is it "friendly"? Is it "proactive"? Does it give the > reporter a warm feeling in their stomach? > > No. Hey Dave Lawrence... Is there a way to add certain text to certain bugzilla emails, depending on the presence of particular state data? As in, if "WONTFIX" is present, some text that explains what "WONTFIX" means in more positive terms? --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From mharris at www.linux.org.uk Thu May 26 17:50:14 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 26 May 2005 13:50:14 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <604aa79105052609406d7c8278@mail.gmail.com> References: <4293B347.40907@redhat.com> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> Message-ID: <42960C56.8090907@www.linux.org.uk> Jeff Spaleta wrote: > The WONTFIX state screams to some users 'this issue is a waste of my > precious developer time i do not care about this issue and i never > will care about this issue so don't bother refiling it again even if > you do upgrade to the next core and still see the problem.' I'd go one step further, and say that "WONTFIX" state, even when accompanied with a friendly explanation, more often than not is interpreted as "F*** O** and DIE, WE DON'T CARE!!!" by a lot of people. And if not that harsh, it is at least interpreted very negatively and usually triggers negative harsh comments in return. An additional note about my suggestions in the thread so far, is that this is largely a psychological issue. The end result is the same wether we say something polite and friendly, with good intent, and close a bug with a more positive sounding resolution - as it is if we say "This issue is very low priority, and we're not going to dedicate the resources to fix it. Closing WONTFIX." The psychological effects of saying "WONT", "CANT", "DONT", "NOT*" are to stimulate a negative experience in the mind of the reader, and should be avoided if at all possible. With a bit of practice, I've changed the way I respond to bugs to almost always use positive phrases, and before submitting my comment, I seek out all negative words, and try to rephrase with positive words, unless I am sure the negative makes sense and wont be taken in a bad way. It's generally not that hard to do. Or should I reword that and say: It's generally fairly easy to do. ;o) From mharris at www.linux.org.uk Thu May 26 17:52:29 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Thu, 26 May 2005 13:52:29 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <42960A4F.3080502@www.linux.org.uk> Message-ID: <42960CDD.8030806@www.linux.org.uk> Greg DeKoenigsberg wrote: > On Thu, 26 May 2005, Mike A. Harris wrote: > > >>I disagree. There are different ways to say the same thing, and >>while "WONTFIX" is very much true, it is NOT the best way of saying >>it. Or should I say instead - There are better ways of saying >>"WONTFIX" that are more positive and friendly. >> >>One could argue GO_TO_HELL is a "true" resolution for some bugs, >>but is it "friendly"? Is it "proactive"? Does it give the >>reporter a warm feeling in their stomach? >> >>No. > > > Hey Dave Lawrence... > > Is there a way to add certain text to certain bugzilla emails, depending > on the presence of particular state data? > > As in, if "WONTFIX" is present, some text that explains what "WONTFIX" > means in more positive terms? Having to explain what "WONTFIX" means in more positive terms, clearly shows that it is a poorly worded resolution that should be replaced with something better - even if it means making a few replacments. If we choose things that are friendly and positive by default, we don't have to explain ourselves and walk on broken glass, which is almost always the case with WONTFIX/NOTABUG. I'm very strongly in favour of removing the negative resolutions from bugzilla and forcing us to creatively solve the problem by coming up with positive replacements. ;o) From gdk at redhat.com Thu May 26 17:58:15 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Thu, 26 May 2005 13:58:15 -0400 (EDT) Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42960CDD.8030806@www.linux.org.uk> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <42960A4F.3080502@www.linux.org.uk> <42960CDD.8030806@www.linux.org.uk> Message-ID: On Thu, 26 May 2005, Mike A. Harris wrote: > Having to explain what "WONTFIX" means in more positive terms, > clearly shows that it is a poorly worded resolution that should > be replaced with something better - even if it means making > a few replacments. I'm in agreement with this, but tactically, one of these solutions is likely to be quite simple, and one is likely to be an impossible political nightmare. :) --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ From dkl at redhat.com Thu May 26 18:01:38 2005 From: dkl at redhat.com (Dave Lawrence) Date: Thu, 26 May 2005 14:01:38 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <42960A4F.3080502@www.linux.org.uk> Message-ID: <42960F02.1000609@redhat.com> Greg DeKoenigsberg wrote: >On Thu, 26 May 2005, Mike A. Harris wrote: > > > >>I disagree. There are different ways to say the same thing, and >>while "WONTFIX" is very much true, it is NOT the best way of saying >>it. Or should I say instead - There are better ways of saying >>"WONTFIX" that are more positive and friendly. >> >>One could argue GO_TO_HELL is a "true" resolution for some bugs, >>but is it "friendly"? Is it "proactive"? Does it give the >>reporter a warm feeling in their stomach? >> >>No. >> >> > >Hey Dave Lawrence... > >Is there a way to add certain text to certain bugzilla emails, depending >on the presence of particular state data? > >As in, if "WONTFIX" is present, some text that explains what "WONTFIX" >means in more positive terms? > >--g > >_____________________ ____________________________________________ > Greg DeKoenigsberg ] [ the future masters of technology will have > Community Relations ] [ to be lighthearted and intelligent. the > Red Hat ] [ machine easily masters the grim and the > ] [ dumb. --mcluhan > Red Hat Summit ] [ > New Orleans ] [ Learn. Network. Experience Open Source. > June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) > [ http://www.redhat.com/promo/summit/ > > > Not without hacking the BZ code with some If/Else conditions. We could change the help text on the page that explains each of the resolutions to be more friendly and place a link to that page in each of the emails that go out if a status change is made. https://bugzilla.redhat.com/bugzilla/page.cgi?id=bug_status.html Dave -- ------------------------------- David Lawrence Red Hat Quality Assurance ------------------------------- www.redhat.com ftp.redhat.com From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 26 19:28:25 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 26 May 2005 21:28:25 +0200 Subject: Stricter rpmbuild with unpackaged files In-Reply-To: <1116860524.16089.1.camel@enki.eridu> References: <1116860524.16089.1.camel@enki.eridu> Message-ID: <20050526212825.63c03b93@python2> Paul Nasrat wrote : > The unpackaged files checks now catch unpackaged symlinks. As per FC4 > tracker request > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108778 Could this have caused nasty side-effects? As of today, my mach chroots (tested on x86_64 and ppc) had builds fail with rpmbuild complaining about unpackaged files... which were symlinks in the both cases I encountered. The thing is, they _were_ listed in %files, and when I tried also listing them explicitly (it was a wildcard previously), then it failed with the same unpackaged files message _and_ complained that they were listed twice :-/ I got really puzzled and just set my rpmmacros to not terminate builds on unpackaged files for now. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.09 0.32 0.35 From pnasrat at redhat.com Thu May 26 19:55:50 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 26 May 2005 15:55:50 -0400 Subject: Stricter rpmbuild with unpackaged files In-Reply-To: <20050526212825.63c03b93@python2> References: <1116860524.16089.1.camel@enki.eridu> <20050526212825.63c03b93@python2> Message-ID: <1117137350.3225.22.camel@enki.eridu> On Thu, 2005-05-26 at 21:28 +0200, Matthias Saou wrote: > Paul Nasrat wrote : > > > The unpackaged files checks now catch unpackaged symlinks. As per FC4 > > tracker request > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108778 > > Could this have caused nasty side-effects? As of today, my mach chroots > (tested on x86_64 and ppc) had builds fail with rpmbuild complaining about > unpackaged files... which were symlinks in the both cases I encountered. > The thing is, they _were_ listed in %files, and when I tried also listing > them explicitly (it was a wildcard previously), then it failed with the > same unpackaged files message _and_ complained that they were listed > twice :-/ This shouldn't have happened AFAIK. Could you please file in bugzilla with a simple reproducible spec. Paul From bugs.michael at gmx.net Thu May 26 19:59:28 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 26 May 2005 21:59:28 +0200 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42960A4F.3080502@www.linux.org.uk> References: <20050524225412.GA24363@jadzia.bu.edu> <4293B347.40907@redhat.com> <20050524234344.GB25882@jadzia.bu.edu> <4293C5BE.1030008@redhat.com> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <42960A4F.3080502@www.linux.org.uk> Message-ID: <20050526215928.43e908b1.bugs.michael@gmx.net> On Thu, 26 May 2005 13:41:35 -0400, Mike A. Harris wrote: > >>>>Is there a reason not to leave such bugs in NEEDINFO state forever? > >> > >>>Yes. Then there are 100000 bugs open forever, that will never > >>>be addressed. > >> > >>Fair enough. What about adding a resolution category "closed for lack > >>of information", which we could use if something stays in NEEDINFO > >>too long? Or I suppose we could use WORKSFORME ... > > > > > > NEEDINFO -> no reply -> WONTFIX : that really is the most true > > resolution. Without feedback, the bug won't be fixed because it won't be > > examined further. Just explain that when closing the ticket. Keep in mind > > that the reporter can reopen the ticket as soon as new feedback is > > provided. > > I disagree. There are different ways to say the same thing, and > while "WONTFIX" is very much true, it is NOT the best way of saying > it. Or should I say instead - There are better ways of saying > "WONTFIX" that are more positive and friendly. > > One could argue GO_TO_HELL is a "true" resolution for some bugs, > but is it "friendly"? Is it "proactive"? Does it give the > reporter a warm feeling in their stomach? > > No. Well, bugzilla.fedora.us has RESOLVED/REMIND -- if the plan is to add new resolutions or rename existing ones, I'm all for doing that. I only thought that a WONTFIX cannot look negative if the added comment gives the rationale. From jorton at redhat.com Fri May 27 11:09:47 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 27 May 2005 12:09:47 +0100 Subject: FC4 setuid executable changes Message-ID: <20050527110947.GC17268@redhat.com> Here's the diff of changes in setuid apps since FC3: cpufreq-selector and vboxbeep look dubious; also sudoedit? --- FC3 2005-05-27 12:07:04.000000000 +0100 +++ FC4 2005-05-27 12:06:41.000000000 +0100 +/usr/bin/cpufreq-selector root root -rwsr-xr-x -/usr/bin/gnuchess root games -rwxr-sr-x -/usr/bin/Maelstrom root games -rwxr-sr-x -/usr/bin/newgrp root root -rws--x--x +/usr/bin/newgrp root root -rwsr-xr-x +/usr/bin/screen root utmp -rwxr-sr-x -/usr/bin/sperl5.8.5 root root -rws--x--x +/usr/bin/sperl5.8.6 root root -rws--x--x +/usr/bin/sudoedit root root ---s--x--x +/usr/bin/vboxbeep root root -rwsr-xr-x -/usr/lib/cyrus-imapd/deliver cyrus mail -rwsr-xr-- -/usr/lib/mailman/pythonlib/lib/python2.3 root mailman drwxrwsr-x -/usr/lib/mailman/pythonlib/lib/python2.3/site-packages root mailman drwxrwsr-x +/usr/lib/mailman/pythonlib/lib/python2.4 root mailman drwxrwsr-x +/usr/lib/mailman/pythonlib/lib/python2.4/site-packages root mailman drwxrwsr-x -/usr/sbin/exim root root -rwsr-xr-x From wtogami at redhat.com Fri May 27 11:15:12 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 27 May 2005 01:15:12 -1000 Subject: FC4 setuid executable changes In-Reply-To: <20050527110947.GC17268@redhat.com> References: <20050527110947.GC17268@redhat.com> Message-ID: <42970140.5080308@redhat.com> Joe Orton wrote: > Here's the diff of changes in setuid apps since FC3: > > cpufreq-selector and vboxbeep look dubious; also sudoedit? > > > -/usr/bin/sperl5.8.5 root root -rws--x--x > +/usr/bin/sperl5.8.6 root root -rws--x--x > As discussed earlier on fedora-perl-devel-list, there seemingly is no good reason to have this versioned suid binary along with "sperl". When I asked Chip "why!?" all he said in response was "Symmetry!" /usr/bin/perl /usr/bin/perl5.8.6 This seems like an odd reason. And I don't see any benefit to keeping either versioned binary. Is this another strange upstream perl thing? Too late to remove it now... but I'm thinking we should remove it in the future unless someone finds some good reason to keep it. Warren Togami wtogami at redhat.com From mattdm at mattdm.org Fri May 27 12:21:36 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 27 May 2005 08:21:36 -0400 Subject: FC4 setuid executable changes In-Reply-To: <20050527110947.GC17268@redhat.com> References: <20050527110947.GC17268@redhat.com> Message-ID: <20050527122136.GA3565@jadzia.bu.edu> On Fri, May 27, 2005 at 12:09:47PM +0100, Joe Orton wrote: > Here's the diff of changes in setuid apps since FC3: [...] > -/usr/bin/newgrp root root -rws--x--x > +/usr/bin/newgrp root root -rwsr-xr-x Hmmmm -- seems like keepin' em non-readable isn't a huge gain in the days of open source, but still, is there a reason *not* to do it? > +/usr/bin/screen root utmp -rwxr-sr-x Isn't there 'utempter' to deal with this? [...] > +/usr/bin/sudoedit root root ---s--x--x I think this is just a hardlink to the existing sudo program: -e The -e (edit) option indicates that, instead of running a command, the user wishes to edit one or more files. In lieu of a command, the string ``sudoedit'' is used when consulting the sudoers file. If the user is authorized by sudoers the following steps are taken: 1. Temporary copies are made of the files to be edited with the owner set to the invoking user. 2. The editor specified by the VISUAL or EDITOR environment variables is run to edit the temporary files. If neither VISUAL nor EDITOR are set, the program listed in the editor sudoers variable is used. 3. If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From mattdm at mattdm.org Fri May 27 12:23:03 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 27 May 2005 08:23:03 -0400 Subject: FC4 setuid executable changes In-Reply-To: <42970140.5080308@redhat.com> References: <20050527110947.GC17268@redhat.com> <42970140.5080308@redhat.com> Message-ID: <20050527122303.GB3565@jadzia.bu.edu> On Fri, May 27, 2005 at 01:15:12AM -1000, Warren Togami wrote: > As discussed earlier on fedora-perl-devel-list, there seemingly is no > good reason to have this versioned suid binary along with "sperl". When > I asked Chip "why!?" all he said in response was "Symmetry!" > > /usr/bin/perl > /usr/bin/perl5.8.6 > > This seems like an odd reason. And I don't see any benefit to keeping > either versioned binary. Is this another strange upstream perl thing? > > Too late to remove it now... but I'm thinking we should remove it in the > future unless someone finds some good reason to keep it. It's pretty typical perl practice to be able to reference perl as a versioned binary. And I believe it's just a link, not a separate file. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 73 degrees Fahrenheit. From bressers at redhat.com Fri May 27 12:44:11 2005 From: bressers at redhat.com (Josh Bressers) Date: Fri, 27 May 2005 08:44:11 -0400 Subject: FC4 setuid executable changes In-Reply-To: Message from Joe Orton of "Fri, 27 May 2005 12:09:47 BST." <20050527110947.GC17268@redhat.com> Message-ID: <200505271244.j4RCiBl7022638@devserv.devel.redhat.com> > Here's the diff of changes in setuid apps since FC3: > > cpufreq-selector and vboxbeep look dubious; also sudoedit? screen shouldn't be suid either. Once everyone is happy with these changes, I can fix up the new FC4 suid whitelist (being the keeper of such a thing). -- JB From notting at redhat.com Fri May 27 16:08:43 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 May 2005 12:08:43 -0400 Subject: FC4 setuid executable changes In-Reply-To: <20050527110947.GC17268@redhat.com> References: <20050527110947.GC17268@redhat.com> Message-ID: <20050527160843.GC8744@nostromo.devel.redhat.com> Joe Orton (jorton at redhat.com) said: > +/usr/bin/screen root utmp -rwxr-sr-x This looks wrong.... if it's using utempter, why is it setgid? Bill From mattdm at mattdm.org Fri May 27 16:23:51 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 27 May 2005 12:23:51 -0400 Subject: FC4 setuid executable changes In-Reply-To: <20050527160843.GC8744@nostromo.devel.redhat.com> References: <20050527110947.GC17268@redhat.com> <20050527160843.GC8744@nostromo.devel.redhat.com> Message-ID: <20050527162351.GA12374@jadzia.bu.edu> On Fri, May 27, 2005 at 12:08:43PM -0400, Bill Nottingham wrote: > > +/usr/bin/screen root utmp -rwxr-sr-x > This looks wrong.... if it's using utempter, why is it setgid? I wondered too, so I poked into it a bit... last changelog entry: * Tue Mar 29 2005 Petr Rockai - 4.0.2-8 - fix BR 150392 by implementing the setgid/utmp scheme for socket directory And Looks like it basically comes down to the "private tmpdir" issue.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From notting at redhat.com Fri May 27 16:32:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 May 2005 12:32:00 -0400 Subject: FC4 setuid executable changes In-Reply-To: <20050527162351.GA12374@jadzia.bu.edu> References: <20050527110947.GC17268@redhat.com> <20050527160843.GC8744@nostromo.devel.redhat.com> <20050527162351.GA12374@jadzia.bu.edu> Message-ID: <20050527163200.GA21568@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > > On Fri, May 27, 2005 at 12:08:43PM -0400, Bill Nottingham wrote: > > > +/usr/bin/screen root utmp -rwxr-sr-x > > This looks wrong.... if it's using utempter, why is it setgid? > > I wondered too, so I poked into it a bit... last changelog entry: > > * Tue Mar 29 2005 Petr Rockai - 4.0.2-8 > - fix BR 150392 by implementing the setgid/utmp scheme for socket directory > > And > > Looks like it basically comes down to the "private tmpdir" issue.... Hm, so utmp was chosen as a random group b/c it happened to already be setgid utmp on some other distro? Bad idea. Bill From mattdm at mattdm.org Fri May 27 18:04:12 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 27 May 2005 14:04:12 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42960C56.8090907@www.linux.org.uk> References: <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> <42960C56.8090907@www.linux.org.uk> Message-ID: <20050527180412.GA16193@jadzia.bu.edu> On Thu, May 26, 2005 at 01:50:14PM -0400, Mike A. Harris wrote: > The psychological effects of saying "WONT", "CANT", "DONT", > "NOT*" are to stimulate a negative experience in the mind > of the reader, and should be avoided if at all possible. This would lend support to using "DEFERRED". Anyway, thanks everyone for your comments. For right now, I'm going to leave all the bugs in NEEDINFO state while I reflect on everything. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From mattdm at mattdm.org Fri May 27 18:14:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 27 May 2005 14:14:44 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050527180412.GA16193@jadzia.bu.edu> References: <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <604aa79105052509045957fa84@mail.gmail.com> <4295E522.7060406@www.linux.org.uk> <20050526155921.GA1841@jadzia.bu.edu> <604aa79105052609406d7c8278@mail.gmail.com> <42960C56.8090907@www.linux.org.uk> <20050527180412.GA16193@jadzia.bu.edu> Message-ID: <20050527181444.GA16723@jadzia.bu.edu> On Fri, May 27, 2005 at 02:04:12PM -0400, Matthew Miller wrote: > Anyway, thanks everyone for your comments. For right now, I'm going to leave > all the bugs in NEEDINFO state while I reflect on everything. (Not that I'm going to do anything rash when I'm done reflecting.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From notting at redhat.com Fri May 27 18:47:02 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 27 May 2005 14:47:02 -0400 Subject: FC4 setuid executable changes In-Reply-To: <20050527110947.GC17268@redhat.com> References: <20050527110947.GC17268@redhat.com> Message-ID: <20050527184702.GA13876@nostromo.devel.redhat.com> Joe Orton (jorton at redhat.com) said: > --- FC3 2005-05-27 12:07:04.000000000 +0100 > +++ FC4 2005-05-27 12:06:41.000000000 +0100 > > +/usr/bin/cpufreq-selector root root -rwsr-xr-x Setuid bit removed in gnome-applets-2.10.1-9; changed to a consolehelper app. > +/usr/bin/screen root utmp -rwxr-sr-x Changed to setgid 'screen' in 4.0.2-9. > +/usr/bin/sudoedit root root ---s--x--x As mentioned, a hardlink to /usr/bin/sudo, so no big deal. > +/usr/bin/vboxbeep root root -rwsr-xr-x Setuid bit removed in 3.2-28. Bill From smooge at gmail.com Sun May 29 05:00:36 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sat, 28 May 2005 23:00:36 -0600 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050526174311.1aa3c48d.bugs.michael@gmx.net> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> Message-ID: <80d7e409050528220078cb9b35@mail.gmail.com> On 5/26/05, Michael Schwendt wrote: > On Thu, 26 May 2005 11:08:33 -0400, Tom Lane wrote: > > > "Mike A. Harris" writes: > > > Tom Lane wrote: > > >> Is there a reason not to leave such bugs in NEEDINFO state forever? > > > > > Yes. Then there are 100000 bugs open forever, that will never > > > be addressed. > > > > Fair enough. What about adding a resolution category "closed for lack > > of information", which we could use if something stays in NEEDINFO > > too long? Or I suppose we could use WORKSFORME ... > > NEEDINFO -> no reply -> WONTFIX : that really is the most true > resolution. Without feedback, the bug won't be fixed because it won't be > examined further. Just explain that when closing the ticket. Keep in mind > that the reporter can reopen the ticket as soon as new feedback is > provided. Actually a better resolution would be CANTFIX_WO_INFO (resting). or just CANTFIX This is a better answer in some cases to WONTFIX... but leads to even more bugzilla choices... (Some anthropologist looking at this in 100 years will say "Bugzilla users like eskimos had 200 ways of saying CLOSED.) -- Stephen J Smoogen. CSIRT/Linux System Administrator From wtogami at redhat.com Sun May 29 05:06:03 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 28 May 2005 19:06:03 -1000 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <80d7e409050528220078cb9b35@mail.gmail.com> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> Message-ID: <42994DBB.1000702@redhat.com> Stephen J. Smoogen wrote: > > CANTFIX > > This is a better answer in some cases to WONTFIX... but leads to even > more bugzilla choices... (Some anthropologist looking at this in 100 > years will say "Bugzilla users like eskimos had 200 ways of saying > CLOSED.) > > I think it should have been CANTFIX instead of WONTFIX from the beginning. Are there really cases where CANTFIX doesn't fit a situation where you mean WONTFIX? Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Sun May 29 05:10:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 29 May 2005 01:10:39 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42994DBB.1000702@redhat.com> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> Message-ID: <1117343439.2499.20.camel@cutter> On Sat, 2005-05-28 at 19:06 -1000, Warren Togami wrote: > Stephen J. Smoogen wrote: > > > > CANTFIX > > > > This is a better answer in some cases to WONTFIX... but leads to even > > more bugzilla choices... (Some anthropologist looking at this in 100 > > years will say "Bugzilla users like eskimos had 200 ways of saying > > CLOSED.) > > > > > > I think it should have been CANTFIX instead of WONTFIX from the > beginning. Are there really cases where CANTFIX doesn't fit a situation > where you mean WONTFIX? > Sure, when you're closing crack RFE requests. I've closed a number of items with wontfix when I really wanted to say 'this is an extremely bad idea' -sv From smooge at gmail.com Sun May 29 05:16:29 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Sat, 28 May 2005 23:16:29 -0600 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42994DBB.1000702@redhat.com> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> Message-ID: <80d7e40905052822163308da48@mail.gmail.com> It depends on the mindframe of the person I think. Originally QA was dealing with a lot of things that no one had time to look at.. and Mike was more of a "tell it to them bluntly" type person. In a larger "find someone in the community to fix it" or "pony up the bennies" style, you should take a more conversational style that gives better explanations of why it isnt being looked at. On 5/28/05, Warren Togami wrote: > Stephen J. Smoogen wrote: > > > > CANTFIX > > > > This is a better answer in some cases to WONTFIX... but leads to even > > more bugzilla choices... (Some anthropologist looking at this in 100 > > years will say "Bugzilla users like eskimos had 200 ways of saying > > CLOSED.) > > > > > > I think it should have been CANTFIX instead of WONTFIX from the > beginning. Are there really cases where CANTFIX doesn't fit a situation > where you mean WONTFIX? > > Warren Togami > wtogami at redhat.com > -- Stephen J Smoogen. CSIRT/Linux System Administrator From bugs.michael at gmx.net Sun May 29 14:34:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 May 2005 16:34:22 +0200 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <42994DBB.1000702@redhat.com> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> Message-ID: <20050529163422.506dd4c4.bugs.michael@gmx.net> On Sat, 28 May 2005 19:06:03 -1000, Warren Togami wrote: > Stephen J. Smoogen wrote: > > > > CANTFIX > > > > This is a better answer in some cases to WONTFIX... but leads to even > > more bugzilla choices... (Some anthropologist looking at this in 100 > > years will say "Bugzilla users like eskimos had 200 ways of saying > > CLOSED.) > > > > > > I think it should have been CANTFIX instead of WONTFIX from the > beginning. Are there really cases where CANTFIX doesn't fit a situation > where you mean WONTFIX? In cases like this, a ticket should be just "CLOSED" without a second resolution or with resolution "SEECOMMENT". The rationale for closing the bug can be added as a comment. The primary problem seems to be that the "Resolution" setting is _the_ source of misunderstandings. WONTFIX upsets users. CANTFIX makes the developers look bad. From gdk at redhat.com Sun May 29 15:49:35 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Sun, 29 May 2005 11:49:35 -0400 (EDT) Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050529163422.506dd4c4.bugs.michael@gmx.net> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> Message-ID: Maybe the real answer is that there should be bug state for bugs that are closed without having been fixed: CLOSED NOTFIXED. Not judgmental, just factual. And for comments, check the bug. /me wonders if bugzilla can be tweaked not to allow someone to close a bug NOTFIXED without adding a comment first... --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ On Sun, 29 May 2005, Michael Schwendt wrote: > On Sat, 28 May 2005 19:06:03 -1000, Warren Togami wrote: > > > Stephen J. Smoogen wrote: > > > > > > CANTFIX > > > > > > This is a better answer in some cases to WONTFIX... but leads to even > > > more bugzilla choices... (Some anthropologist looking at this in 100 > > > years will say "Bugzilla users like eskimos had 200 ways of saying > > > CLOSED.) > > > > > > > > > > I think it should have been CANTFIX instead of WONTFIX from the > > beginning. Are there really cases where CANTFIX doesn't fit a situation > > where you mean WONTFIX? > > In cases like this, a ticket should be just "CLOSED" without a second > resolution or with resolution "SEECOMMENT". The rationale for closing the > bug can be added as a comment. The primary problem seems to be that the > "Resolution" setting is _the_ source of misunderstandings. WONTFIX upsets > users. CANTFIX makes the developers look bad. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From bugs.michael at gmx.net Sun May 29 16:00:56 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 29 May 2005 18:00:56 +0200 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> Message-ID: <20050529180056.653cf3dd.bugs.michael@gmx.net> On Sun, 29 May 2005 11:49:35 -0400 (EDT), Greg DeKoenigsberg wrote: > > Maybe the real answer is that there should be bug state for bugs that are > closed without having been fixed: > > CLOSED NOTFIXED. > > Not judgmental, just factual. And for comments, check the bug. It implies too much. It can be inaccurate (false even) and misleading again in all the cases where a reporter didn't reply to NEEDINFO. From gdk at redhat.com Sun May 29 16:11:49 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Sun, 29 May 2005 12:11:49 -0400 (EDT) Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050529180056.653cf3dd.bugs.michael@gmx.net> References: <20050524225412.GA24363@jadzia.bu.edu> <20050525022655.GB29828@jadzia.bu.edu> <4293E347.2020309@redhat.com> <20050525030418.GA31087@jadzia.bu.edu> <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> <20050529180056.653cf3dd.bugs.michael@gmx.net> Message-ID: Every state implies too much. The whole problem we're running into here is that people are reading too much into one word. Maybe "CLOSED SEECOMMENT" is the right way to go. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan Red Hat Summit ] [ New Orleans ] [ Learn. Network. Experience Open Source. June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) [ http://www.redhat.com/promo/summit/ On Sun, 29 May 2005, Michael Schwendt wrote: > On Sun, 29 May 2005 11:49:35 -0400 (EDT), Greg DeKoenigsberg wrote: > > > > > Maybe the real answer is that there should be bug state for bugs that are > > closed without having been fixed: > > > > CLOSED NOTFIXED. > > > > Not judgmental, just factual. And for comments, check the bug. > > It implies too much. It can be inaccurate (false even) and misleading > again in all the cases where a reporter didn't reply to NEEDINFO. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From mattdm at mattdm.org Sun May 29 16:14:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 29 May 2005 12:14:39 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050529180056.653cf3dd.bugs.michael@gmx.net> References: <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> <20050529180056.653cf3dd.bugs.michael@gmx.net> Message-ID: <20050529161439.GA25441@jadzia.bu.edu> On Sun, May 29, 2005 at 06:00:56PM +0200, Michael Schwendt wrote: > > CLOSED NOTFIXED. > > Not judgmental, just factual. And for comments, check the bug. > It implies too much. It can be inaccurate (false even) and misleading > again in all the cases where a reporter didn't reply to NEEDINFO. CLOSED NOTADDRESSED? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From jspaleta at gmail.com Sun May 29 16:32:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 29 May 2005 12:32:50 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050529161439.GA25441@jadzia.bu.edu> References: <20050525084841.GA4834@amilo> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> <20050529180056.653cf3dd.bugs.michael@gmx.net> <20050529161439.GA25441@jadzia.bu.edu> Message-ID: <604aa791050529093238630206@mail.gmail.com> On 5/29/05, Matthew Miller wrote: > CLOSED NOTADDRESSED? CLOSED RETURNTOSENDER ADDRESSUNKNOWN -jef"apply clever parody of http://lyrics.rare-lyrics.com/E/Elvis-Presley/Return-To-Sender.html here"spaleta From fedora at camperquake.de Sun May 29 16:48:30 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 29 May 2005 18:48:30 +0200 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <604aa791050529093238630206@mail.gmail.com> References: <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> <20050529180056.653cf3dd.bugs.michael@gmx.net> <20050529161439.GA25441@jadzia.bu.edu> <604aa791050529093238630206@mail.gmail.com> Message-ID: <20050529164830.GA26225@ryoko.camperquake.de> On Sun, May 29, 2005 at 12:32:50PM -0400, Jeff Spaleta wrote: > On 5/29/05, Matthew Miller wrote: > > CLOSED NOTADDRESSED? > > CLOSED > RETURNTOSENDER > ADDRESSUNKNOWN CLOSED ELVIS From ed at eh3.com Sun May 29 17:36:52 2005 From: ed at eh3.com (Ed Hill) Date: Sun, 29 May 2005 13:36:52 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: <20050529164830.GA26225@ryoko.camperquake.de> References: <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> <20050529180056.653cf3dd.bugs.michael@gmx.net> <20050529161439.GA25441@jadzia.bu.edu> <604aa791050529093238630206@mail.gmail.com> <20050529164830.GA26225@ryoko.camperquake.de> Message-ID: <1117388212.28429.54.camel@ernie> On Sun, 2005-05-29 at 18:48 +0200, Ralf Ertzinger wrote: > On Sun, May 29, 2005 at 12:32:50PM -0400, Jeff Spaleta wrote: > > On 5/29/05, Matthew Miller wrote: > > > CLOSED NOTADDRESSED? > > > > CLOSED > > RETURNTOSENDER > > ADDRESSUNKNOWN > > CLOSED ELVIS Oh! You're so close! It ought to be: CLOSED ELVISHASLEFTTHEBULDING -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From dkl at redhat.com Sun May 29 17:49:52 2005 From: dkl at redhat.com (Dave Lawrence) Date: Sun, 29 May 2005 13:49:52 -0400 Subject: The impending end of FC2 NEEDINFO bugs... In-Reply-To: References: <42942B7C.4010605@www.linux.org.uk> <20050525084841.GA4834@amilo> <11601.1117028652@sss.pgh.pa.us> <4295E398.2050502@www.linux.org.uk> <2402.1117120113@sss.pgh.pa.us> <20050526174311.1aa3c48d.bugs.michael@gmx.net> <80d7e409050528220078cb9b35@mail.gmail.com> <42994DBB.1000702@redhat.com> <20050529163422.506dd4c4.bugs.michael@gmx.net> Message-ID: <20050529174952.GA4369@redhat.com> On Sun, May 29, 2005 at 11:49:35AM -0400, Greg DeKoenigsberg claimed: > > Maybe the real answer is that there should be bug state for bugs that are > closed without having been fixed: > > CLOSED NOTFIXED. > > Not judgmental, just factual. And for comments, check the bug. > > /me wonders if bugzilla can be tweaked not to allow someone to close a bug > NOTFIXED without adding a comment first... > Yes it can ;) -- ------------------------------- David Lawrence Red Hat Quality Assurance ------------------------------- www.redhat.com ftp.redhat.com From bugs.michael at gmx.net Mon May 30 11:35:08 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 13:35:08 +0200 Subject: Fedora Extras: missing bugzilla components Message-ID: <20050530133508.6f569b5e.bugs.michael@gmx.net> An increasing number of packages do not have a component entry in bugzilla! What do you need to do? See if your package is on this list and if it is approved, request addition of a bugzilla component entry on this Wiki page: http://fedoraproject.org/wiki/Extras/BugzillaAdmin Offer: reply off-list and state package name(s) and bugzilla account e-mail address, and I request creation of the bugzilla component(s). GiNaC Maelstrom SIMVoleon balsa cdlabelgen cln cvsup enchant enemies-of-carlotta exim-doc exim flumotion fping freenx gnuchess hula kile-i18n lapack milter-greylist mod_security moin nabi nx octave-forge ots rzip syslog-ng tdl util-vserver w3m-el xdaliclock From bugs.michael at gmx.net Mon May 30 16:26:33 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 30 May 2005 18:26:33 +0200 Subject: Fedora Extras: packages with EVR upgrade problems Message-ID: <20050530182633.284959cc.bugs.michael@gmx.net> CVS based %epoch:%version-%release (EVR) comparison. EVR of packages for Fedora Extras Development should be higher than packages for Fedora Extras FC3. The following packages violate this upgrade path: galeon 0:1.3.21-2.fc3 in FC-3 branch is newer than devel gpredict 0:0.5.1-1 in FC-3 branch is newer than devel inadyn 0:1.90-11.fc3 in FC-3 branch is newer than devel c-ares 0:1.2.1-2 in FC-3 branch is equal to devel flumotion 0:0.1.8-1 in FC-3 branch is equal to devel ghc 0:6.4-8 in FC-3 branch is equal to devel iozone 0:3-1 in FC-3 branch is equal to devel From sopwith at redhat.com Mon May 30 20:14:43 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 30 May 2005 16:14:43 -0400 (EDT) Subject: Making FC-4 branches in CVS (Core & Extras) Message-ID: Just a heads-up that the branching of Fedora Core and Fedora Extras CVS repos is imminent. This means that the devel branch will start to be used for Fedora Core 5 & Fedora Extras for FC5, while the FC-4 branch will be the place to make updates targetted at FC4. This branching should happen sometime today, depending on the builds that are going on and how the FC4 release shapes up. -- Elliot From petersen at redhat.com Tue May 31 03:12:41 2005 From: petersen at redhat.com (Jens Petersen) Date: Tue, 31 May 2005 12:12:41 +0900 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050530182633.284959cc.bugs.michael@gmx.net> References: <20050530182633.284959cc.bugs.michael@gmx.net> Message-ID: <429BD629.40400@redhat.com> Michael Schwendt wrote: > ghc 0:6.4-8 in FC-3 branch is equal to devel Yep, I already suffixed with %dist in my local tree :) Thanks, Jens From tagoh at redhat.com Tue May 31 03:14:13 2005 From: tagoh at redhat.com (Akira TAGOH) Date: Tue, 31 May 2005 12:14:13 +0900 (JST) Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050530133508.6f569b5e.bugs.michael@gmx.net> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> Message-ID: <20050531.121413.3580252863594990515.tagoh@redhat.com> >>>>> On Mon, 30 May 2005 13:35:08 +0200, >>>>> "MS" == Michael Schwendt wrote: MS> An increasing number of packages do not have a component entry in bugzilla! MS> What do you need to do? See if your package is on this list and if it is MS> approved, request addition of a bugzilla component entry on this Wiki page: MS> http://fedoraproject.org/wiki/Extras/BugzillaAdmin MS> Offer: reply off-list and state package name(s) and bugzilla account e-mail MS> address, and I request creation of the bugzilla component(s). [snip] MS> w3m-el I thought I added it into wiki. but I seem to forgot to do it :) done. -- Akira TAGOH From petersen at redhat.com Tue May 31 03:30:11 2005 From: petersen at redhat.com (Jens Petersen) Date: Tue, 31 May 2005 12:30:11 +0900 Subject: [extras Makefile.common] build target help Message-ID: <429BDA43.9040308@redhat.com> Here is a patchlette to Makefile.common to document the "build" target. I guess ideally this and the build target should be conditioned for only a non-anoncvs checkout, but perhaps that is overkill? Also I intentioally didn't explicitly document TAG and TARGET: anyone think they should be? -Jens -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common-build-help.patch Type: text/x-patch Size: 682 bytes Desc: not available URL: From katzj at redhat.com Tue May 31 03:33:35 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 30 May 2005 23:33:35 -0400 Subject: [extras Makefile.common] build target help In-Reply-To: <429BDA43.9040308@redhat.com> References: <429BDA43.9040308@redhat.com> Message-ID: <1117510415.3849.14.camel@bree.local.net> On Tue, 2005-05-31 at 12:30 +0900, Jens Petersen wrote: > Here is a patchlette to Makefile.common to document the "build" target. Applied. > I guess ideally this and the build target should be conditioned > for only a non-anoncvs checkout, but perhaps that is overkill? Yeah, I don't think it's worth conditionalizing the things that only work for a non-anon user. There are a number of things in that case. > Also I intentioally didn't explicitly document TAG and TARGET: > anyone think they should be? Nope, they get set automatically and don't really allow overriding now. Jeremy From tcallawa at redhat.com Tue May 31 14:42:29 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 31 May 2005 09:42:29 -0500 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050530133508.6f569b5e.bugs.michael@gmx.net> References: <20050530133508.6f569b5e.bugs.michael@gmx.net> Message-ID: <1117550549.3991.39.camel@localhost.localdomain> On Mon, 2005-05-30 at 13:35 +0200, Michael Schwendt wrote: > An increasing number of packages do not have a component entry in bugzilla! > lapack Lapack used to be in older versions of FC, got pulled out of FC-4 so I took over ownership of it in FE. I requested that I be the bugzilla owner for FC-4, and the entry disappeared, so I assumed it was done... ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tcallawa at redhat.com Tue May 31 14:47:43 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 31 May 2005 09:47:43 -0500 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050530182633.284959cc.bugs.michael@gmx.net> References: <20050530182633.284959cc.bugs.michael@gmx.net> Message-ID: <1117550863.3991.41.camel@localhost.localdomain> On Mon, 2005-05-30 at 18:26 +0200, Michael Schwendt wrote: > CVS based %epoch:%version-%release (EVR) comparison. EVR of packages for > Fedora Extras Development should be higher than packages for Fedora Extras > FC3. The following packages violate this upgrade path: > c-ares 0:1.2.1-2 in FC-3 branch is equal to devel Fixed in cvs, new tags and builds requested. Thanks, ~spot -- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From sopwith at redhat.com Tue May 31 18:51:04 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 31 May 2005 14:51:04 -0400 (EDT) Subject: CVS branching is done Message-ID: I've created FC-4 branches for all the Fedora Extras packages, and for all the packages included in Fedora Core 4. For distro CVS, the devel branch is targetting FC5 now and the FC-4 branch needs to be used for all FC4 updates. For extras CVS, the devel branch is for packages on top of rawhide (FC5-to-be), and the FC-4 branch needs to be used for the FE4 release/updates. Best, -- Elliot From skvidal at phy.duke.edu Tue May 31 18:58:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 May 2005 14:58:02 -0400 Subject: requesting builds Message-ID: <1117565882.18404.33.camel@cutter> Hi Folks, could you cool it on requesting builds while I finish migrating things to work for builds with devel == FC5 and FC4 existing? thanks -sv From skvidal at phy.duke.edu Tue May 31 22:01:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 31 May 2005 18:01:02 -0400 Subject: Fedora Extras 4/Fedora Extras Development Message-ID: <1117576862.18404.62.camel@cutter> Ok Folks, The Extras 4 tree has been made and development is now for builds for to-be-FC5 in the buildsystem. I wonder what will break. :) -sv