From ville.skytta at iki.fi Sun Apr 3 20:57:30 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 03 Apr 2005 23:57:30 +0300 Subject: RFD: kernel-devel package improvements In-Reply-To: <1112188228.27816.62.camel@anu.eridu> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> Message-ID: <1112561850.24368.104.camel@bobcat.mine.nu> On Wed, 2005-03-30 at 14:10 +0100, Paul Nasrat wrote: > On Tue, 2005-03-29 at 14:57 -0500, Rik van Riel wrote: > > > And indeed, RPM isn't able to install both the i586 and > > i686 version of the kernel-devel package, even though > > there are no file conflicts. > > > > # rpm -ivh i686/kernel-devel-2.6.11-1.1208_FC4.i686.rpm i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm > > warning: package kernel-devel = 2.6.11-1.1208_FC4 was already added, skipping kernel-devel < 2.6.11-1.1208_FC4 > > Try in two seperate runs rather than the same transaction. Does not matter. https://bugzilla.redhat.com/147553 # rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n" kernel-devel kernel-devel-2.6.11-1.1225_FC4.i686 # rpm -ivh kernel-devel-2.6.11-1.1225_FC4.i586.rpm Preparing... ########################################### [100%] package kernel-devel-2.6.11-1.1225_FC4 is already installed From ville.skytta at iki.fi Sun Apr 3 20:59:54 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 03 Apr 2005 23:59:54 +0300 Subject: RFD: kernel-devel package improvements In-Reply-To: References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> Message-ID: <1112561994.24368.108.camel@bobcat.mine.nu> On Tue, 2005-03-29 at 14:57 -0500, Rik van Riel wrote: > On Mon, 28 Mar 2005, Ville Skytt? wrote: > > > If the two RFEs/patches above would be accepted, I think we'd have a > > complete, easy-to-use, and consistent "interface" in place for kernel > > module packagers. > > I just committed these, so they should be in the next > Rawhide kernel. A late reply, got around to these yesterday and today: thanks a lot, I think the basic infrastructure is in place now. Will try to find time soon to document this part of kernel module packaging in the Wiki. From riel at redhat.com Mon Apr 4 03:45:46 2005 From: riel at redhat.com (Rik van Riel) Date: Sun, 3 Apr 2005 23:45:46 -0400 (EDT) Subject: RFD: kernel-devel package improvements In-Reply-To: <1112561850.24368.104.camel@bobcat.mine.nu> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> Message-ID: On Sun, 3 Apr 2005, Ville Skytt? wrote: > Does not matter. https://bugzilla.redhat.com/147553 > > # rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n" kernel-devel > kernel-devel-2.6.11-1.1225_FC4.i686 > # rpm -ivh kernel-devel-2.6.11-1.1225_FC4.i586.rpm > Preparing... ########################################### [100%] > package kernel-devel-2.6.11-1.1225_FC4 is already installed I am inclined to just not fix this - how important is it to build the external kernel modules for i586 ? This multi-arch issue should not happen with i686 vs x86-64, or with ppc vs ppc64, because RPM knows that those architectures really are different, and it should be able to just install the kernel-devel packages side by side. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From fedora at leemhuis.info Mon Apr 4 04:49:58 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 04 Apr 2005 06:49:58 +0200 Subject: RFD: kernel-devel package improvements In-Reply-To: References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> Message-ID: <1112590198.14994.5.camel@thl.ct.heise.de> Am Sonntag, den 03.04.2005, 23:45 -0400 schrieb Rik van Riel: > On Sun, 3 Apr 2005, Ville Skytt? wrote: > > > Does not matter. https://bugzilla.redhat.com/147553 > > > > # rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n" kernel-devel > > kernel-devel-2.6.11-1.1225_FC4.i686 > > # rpm -ivh kernel-devel-2.6.11-1.1225_FC4.i586.rpm > > Preparing... ########################################### [100%] > > package kernel-devel-2.6.11-1.1225_FC4 is already installed > > I am inclined to just not fix this - how important is it to > build the external kernel modules for i586 ? Okay, if we argue that way we also could stop providing i586 kernels in FC. Okay, okay, no flamewar please, don't take that serious. Yes, probably nearly nobody needs a ati or a nvidia driver for a i586 machine (but we provide them on livna). But ntfs and/or GFS (or insert something that else that may arise in the future) might me of interest. CU thl From davej at redhat.com Mon Apr 4 05:26:40 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 4 Apr 2005 01:26:40 -0400 Subject: RFD: kernel-devel package improvements In-Reply-To: <1112590198.14994.5.camel@thl.ct.heise.de> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> Message-ID: <20050404052640.GC433@redhat.com> On Mon, Apr 04, 2005 at 06:49:58AM +0200, Thorsten Leemhuis wrote: > Am Sonntag, den 03.04.2005, 23:45 -0400 schrieb Rik van Riel: > > On Sun, 3 Apr 2005, Ville Skytt? wrote: > > > > > Does not matter. https://bugzilla.redhat.com/147553 > > > > > > # rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n" kernel-devel > > > kernel-devel-2.6.11-1.1225_FC4.i686 > > > # rpm -ivh kernel-devel-2.6.11-1.1225_FC4.i586.rpm > > > Preparing... ########################################### [100%] > > > package kernel-devel-2.6.11-1.1225_FC4 is already installed > > > > I am inclined to just not fix this - how important is it to > > build the external kernel modules for i586 ? > > Okay, if we argue that way we also could stop providing i586 kernels in > FC. Okay, okay, no flamewar please, don't take that serious. It's going to have to happen eventually. Already we're seeing situations where users are reporting bugs that we can't diagnose, because a) We don't have the hardware because its so old b) There are bugs affecting far more users that get more attention. At some stage I'd like to see 586 kernel/installer become a spin-off project by people who actually use it. The amount of testing the 586 kernel gets these days is very very minimal. I only recall a single bugzilla against the 586 kernel in many months[*]. Inside Red Hat, 586 kernels get no testing whatsoever before they're pushed out. (My last 586-era box met with an unfortunate accident with a certain transatlantic shipper). Dropping this from Fedora proper would mean we lose support for - AMD K5 - Just say no. These things sucked back in 1996. Anyone trying to run a 2005 userspace on these is either twisted, or in need of something more worthwhile to do. - Pentium 60MHz->200MHz CPUs. (Pre Pentium-Pro). - AMD K6/K6-2/K6-3 - These probably make up the bulk of the 586 users, as these things sold like hot-cakes when they were launched. These might actually still make decent low-usage server/firewall type boxes. The question remains whether Fedora is the right choice for this role. - A few wierdo Cyrix's - Every time this subject comes up, Alan mentions he still has one. I'm sure we could start a collection to replace it with something from the later part of the 1990s if needbe. - See comments about the K5. Early Cyrix were dreadful in my experience. They ran stupidly hot, and performance was very lacklustre. - IDT Winchips - If both the remaining users of this weirdo chip write me, I'll mail them a real 686 :) - Early VIA C3's that lacked CMOV, but were otherwise 686. These are the most compelling reason imo to keep 586 for the time-being, and even now, the newer C3s are cheap enough that the old ones are almost disposable. After a quick google: $37 for a Nehemiah core C3. You may even find them cheaper.. However, this doesn't help the folks who shelled out for the non-socketed embedded variants. For something that gets zero testing, and zero feedback, it's obviously becoming niche enough that either Fedora is perfect, or all its users migrated to more lightweight distros already. As much as I'd like to believe Fedora is perfect, I have a hard time convincing myself that's the reason for the silence from 586 users. Dave [*] VIA EPIA's randomly crashing due to a broken longhaul module. (This is broken upstream, and as upstream maintainer of that code, I can say it isn't going to get fixed any time soon due to a) lack of hardware and b) More important things that need fixing) From dwmw2 at infradead.org Mon Apr 4 10:28:08 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 04 Apr 2005 11:28:08 +0100 Subject: RFD: kernel-devel package improvements In-Reply-To: <20050404052640.GC433@redhat.com> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> <20050404052640.GC433@redhat.com> Message-ID: <1112610489.3899.298.camel@localhost.localdomain> On Mon, 2005-04-04 at 01:26 -0400, Dave Jones wrote: > At some stage I'd like to see 586 kernel/installer become a spin-off > project by people who actually use it. The amount of testing the > 586 kernel gets these days is very very minimal. The dual-586 box which is my primary mail server tests the swap code in the 586 kernel quite hard :) -- dwmw2 From jspaleta at gmail.com Mon Apr 4 13:34:28 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 4 Apr 2005 09:34:28 -0400 Subject: RFD: kernel-devel package improvements In-Reply-To: <20050404052640.GC433@redhat.com> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> <20050404052640.GC433@redhat.com> Message-ID: <604aa791050404063421de41fd@mail.gmail.com> On Apr 4, 2005 1:26 AM, Dave Jones wrote: > - Pentium 60MHz->200MHz CPUs. (Pre Pentium-Pro). > - AMD K6/K6-2/K6-3 > - These probably make up the bulk of the 586 users, as these > things sold like hot-cakes when they were launched. > These might actually still make decent low-usage server/firewall > type boxes. The question remains whether Fedora is the right > choice for this role. they definitely make for decent rdiff-backup servers and web servers. be careful with that last sentence.... since fedora is defined as being "general purpose" fedora is probably not the 'right' choice for any "specific purpose" no matter what hardware you happen to have... be it firewall, web server, or desktop if we want to get pedantic about it. If someone in the community donates i586 hardware to you does that fix your lack of testing hardware problem? The idea that Fedora as a project could currently support community led initiative to keep a 586 Core kernel maintained with a seperate installer inside the Fedora namespace is somewhat laughable. There is absolutely ZERO evidence that Red Hat is prepared to allow for contributed installable media sets that can use the Fedora trademarks, whether it be i386 or i586 specific or anything else. -jef" i havent filed any bugs against i586 kernels..because well.. i havent noticed any problems on my 586 machines"spaleta From alan at redhat.com Mon Apr 4 13:47:14 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 4 Apr 2005 09:47:14 -0400 Subject: RFD: kernel-devel package improvements In-Reply-To: <604aa791050404063421de41fd@mail.gmail.com> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> <20050404052640.GC433@redhat.com> <604aa791050404063421de41fd@mail.gmail.com> Message-ID: <20050404134714.GB22554@devserv.devel.redhat.com> On Mon, Apr 04, 2005 at 09:34:28AM -0400, Jeff Spaleta wrote: > project could currently support community led initiative to keep a 586 > Core kernel maintained with a seperate installer inside the Fedora > namespace is somewhat laughable. Well you only need the 386 kernel to install. The 586 kernel is a small performance tweak (and if we went to 486 base kernel a miniscule one) From jspaleta at gmail.com Mon Apr 4 13:57:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 4 Apr 2005 09:57:09 -0400 Subject: RFD: kernel-devel package improvements In-Reply-To: <20050404134714.GB22554@devserv.devel.redhat.com> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> <20050404052640.GC433@redhat.com> <604aa791050404063421de41fd@mail.gmail.com> <20050404134714.GB22554@devserv.devel.redhat.com> Message-ID: <604aa79105040406571264466a@mail.gmail.com> On Apr 4, 2005 9:47 AM, Alan Cox wrote: > On Mon, Apr 04, 2005 at 09:34:28AM -0400, Jeff Spaleta wrote: > > project could currently support community led initiative to keep a 586 > > Core kernel maintained with a seperate installer inside the Fedora > > namespace is somewhat laughable. > > Well you only need the 386 kernel to install. The technical specifics as to what community would have to do is not the issue. The issue is Red Hat's political will to manage this project in a manner that allows the community the freedom of movement inside the the Fedora namespace to actually build alternative mediasets that can use the Fedora marks. -jef From davej at redhat.com Tue Apr 5 00:30:49 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 4 Apr 2005 20:30:49 -0400 Subject: RFD: kernel-devel package improvements In-Reply-To: <604aa791050404063421de41fd@mail.gmail.com> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> <20050404052640.GC433@redhat.com> <604aa791050404063421de41fd@mail.gmail.com> Message-ID: <20050405003049.GA13435@redhat.com> On Mon, Apr 04, 2005 at 09:34:28AM -0400, Jeff Spaleta wrote: > If someone in the community donates i586 hardware to you does that fix > your lack of testing hardware problem? No. If I have an hour to work on Fedora bugs, I'm going to spend that hour working on bugs affecting the most users. Which mean 586 specific bugs aren't going to get attention. As RHEL doesn't support 586 at all, there's going to be little motivation inside Red Hat to fix any issues that crop up with that kernel. > The idea that Fedora as a > project could currently support community led initiative to keep a 586 > Core kernel maintained with a seperate installer inside the Fedora > namespace is somewhat laughable. Seems you've forgotten about FC1-x86_64 already. That whole project was run by one person. Installer, kernel (though I admit I did lend a hand somewhat there), multilib support, everything. 99% done outside of Red Hat. If one person can pull that off, I see no reason why a handful of interested parties couldn't do the same for something far less complicated. > There is absolutely ZERO evidence that Red Hat is prepared to allow > for contributed installable media sets that can use the Fedora > trademarks, whether it be i386 or i586 specific or anything else. Except for FC1-x86_64. Dave From jspaleta at gmail.com Tue Apr 5 01:01:58 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 4 Apr 2005 21:01:58 -0400 Subject: RFD: kernel-devel package improvements In-Reply-To: <20050405003049.GA13435@redhat.com> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> <20050404052640.GC433@redhat.com> <604aa791050404063421de41fd@mail.gmail.com> <20050405003049.GA13435@redhat.com> Message-ID: <604aa791050404180150786722@mail.gmail.com> On Apr 4, 2005 8:30 PM, Dave Jones wrote: > Seems you've forgotten about FC1-x86_64 already. > That whole project was run by one person. Installer, kernel (though > I admit I did lend a hand somewhat there), multilib support, > everything. 99% done outside of Red Hat. > If one person can pull that off, I see no reason why a handful > of interested parties couldn't do the same for something far > less complicated. > > > There is absolutely ZERO evidence that Red Hat is prepared to allow > > for contributed installable media sets that can use the Fedora > > trademarks, whether it be i386 or i586 specific or anything else. > > Except for FC1-x86_64. You're right.. i've seen to have been exceedingly irrational in this thread, if not for a good chunk of the day in general. I apologize. -jef From skvidal at phy.duke.edu Tue Apr 5 07:17:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 03:17:53 -0400 Subject: BuildRequires on python-abi Message-ID: <1112685473.6556.64.camel@cutter> Hey folks, I was looking at some packages with: BuildRequires: python-abi = %{pyver} when this is in an srpm, built on fc3 it comes out as python-abi = 2.3 when you try to rebuild this srpm on rawhide it is impossible to provide the buildreq b/c nothing provides python-abi = 2.3. So I was thinking - wouldn't it make sense for a buildrequires on python-abi to be >= %{pyver}? -sv From ivazquez at ivazquez.net Tue Apr 5 07:41:36 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 03:41:36 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112685473.6556.64.camel@cutter> References: <1112685473.6556.64.camel@cutter> Message-ID: <1112686897.22212.25.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 03:17 -0400, seth vidal wrote: > I was looking at some packages with: > > BuildRequires: python-abi = %{pyver} > > when this is in an srpm, built on fc3 it comes out as python-abi = 2.3 > when you try to rebuild this srpm on rawhide it is impossible to provide > the buildreq b/c nothing provides python-abi = 2.3. ... That makes NO sense whatsoever. Shouldn't rpmbuild look at the spec file alone for build-time dependencies? Or does --rebuild work differently from -bb? -- 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 Tue Apr 5 07:47:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 03:47:40 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112686897.22212.25.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <1112686897.22212.25.camel@ignacio.ignacio.lan> Message-ID: <1112687261.6556.75.camel@cutter> > That makes NO sense whatsoever. Shouldn't rpmbuild look at the spec file > alone for build-time dependencies? Or does --rebuild work differently > from -bb? it's not about rpmbuild - it's about mach. We have to get the buildreqs from somewhere. So if you read them from the srpm made on fc3 and try to --rebuild the srpm on rawhide they're going to be wrong. Moreover for this package does the buildreq REALLY specifically require only python-abi 2.3? I doubt it. -sv From ivazquez at ivazquez.net Tue Apr 5 07:59:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 03:59:35 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112687261.6556.75.camel@cutter> References: <1112685473.6556.64.camel@cutter> <1112686897.22212.25.camel@ignacio.ignacio.lan> <1112687261.6556.75.camel@cutter> Message-ID: <1112687975.22212.29.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 03:47 -0400, seth vidal wrote: > Moreover for this package does the buildreq REALLY > specifically require only python-abi 2.3? No, it requires python-abi = %{pyver}, exactly as the spec file states. Well, strictly speaking it requires /usr/bin/python%{pyver}, but I presume you'll have the same problem there. Let me do some looking into this. -- 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 Tue Apr 5 08:06:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 04:06:51 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112687975.22212.29.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <1112686897.22212.25.camel@ignacio.ignacio.lan> <1112687261.6556.75.camel@cutter> <1112687975.22212.29.camel@ignacio.ignacio.lan> Message-ID: <1112688411.6556.82.camel@cutter> On Tue, 2005-04-05 at 03:59 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 03:47 -0400, seth vidal wrote: > > Moreover for this package does the buildreq REALLY > > specifically require only python-abi 2.3? > > No, it requires python-abi = %{pyver}, exactly as the spec file states. > Well, strictly speaking it requires /usr/bin/python%{pyver}, but I > presume you'll have the same problem there. Right, but we're passing around srpms. They're already made up. It seems a bit inaccurate. To give you a bit more info: - mach reads the buildreqs from the srpms - and tries to satisfy them - it also parses the spec file and tries to satisfy the reqs in there - mostly looking for ifdef's, though, iirc. -sv From jorton at redhat.com Tue Apr 5 08:11:39 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 5 Apr 2005 09:11:39 +0100 Subject: BuildRequires on python-abi In-Reply-To: <1112685473.6556.64.camel@cutter> References: <1112685473.6556.64.camel@cutter> Message-ID: <20050405081139.GA17951@redhat.com> On Tue, Apr 05, 2005 at 03:17:53AM -0400, seth vidal wrote: > Hey folks, > I was looking at some packages with: > > BuildRequires: python-abi = %{pyver} > > when this is in an srpm, built on fc3 it comes out as python-abi = 2.3 > when you try to rebuild this srpm on rawhide it is impossible to provide > the buildreq b/c nothing provides python-abi = 2.3. > > So I was thinking - wouldn't it make sense for a buildrequires on > python-abi to be >= %{pyver}? I expect this was just a braino on someone's part, it should have been Requires not BuildRequires; but the brp-* scripts do it automatically these days so it should probably be removed from spec files on sight now. joe From ivazquez at ivazquez.net Tue Apr 5 08:22:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 04:22:35 -0400 Subject: BuildRequires on python-abi In-Reply-To: <20050405081139.GA17951@redhat.com> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> Message-ID: <1112689355.22212.32.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 09:11 +0100, Joe Orton wrote: > I expect this was just a braino on someone's part, it should have been > Requires not BuildRequires; No, it was deliberate. It's there for the purpose of allowing the package to be built for versions of python other than the primary one, e.g., python-2.4 under FC3. It most likely won't get much use, but who's to say a similar problem won't show up in the future? -- 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 Tue Apr 5 08:27:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 04:27:25 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112689355.22212.32.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> Message-ID: <1112689646.6556.89.camel@cutter> > No, it was deliberate. It's there for the purpose of allowing the > package to be built for versions of python other than the primary one, > e.g., python-2.4 under FC3. It most likely won't get much use, but who's > to say a similar problem won't show up in the future? So wait a sec - you included it so people could build the package for a version of python that's newer/older than the installed one? I think that seems a bit over engineered considering the prominence of python on the system. -sv From jorton at redhat.com Tue Apr 5 08:35:02 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 5 Apr 2005 09:35:02 +0100 Subject: BuildRequires on python-abi In-Reply-To: <1112689355.22212.32.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> Message-ID: <20050405083502.GA18393@redhat.com> On Tue, Apr 05, 2005 at 04:22:35AM -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 09:11 +0100, Joe Orton wrote: > > I expect this was just a braino on someone's part, it should have been > > Requires not BuildRequires; > > No, it was deliberate. It's there for the purpose of allowing the > package to be built for versions of python other than the primary one, > e.g., python-2.4 under FC3. It most likely won't get much use, but who's > to say a similar problem won't show up in the future? I don't see how this makes any sense; the dependency on a particular python ABI is a property of a *binary* package, not a source package. If you have a package which only builds with python >= 2.4 (is that what you're saying?), surely it should just BR: python >= 2.4 or similar? joe From ivazquez at ivazquez.net Tue Apr 5 08:47:47 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 04:47:47 -0400 Subject: BuildRequires on python-abi In-Reply-To: <20050405083502.GA18393@redhat.com> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <20050405083502.GA18393@redhat.com> Message-ID: <1112690867.22212.37.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 09:35 +0100, Joe Orton wrote: > On Tue, Apr 05, 2005 at 04:22:35AM -0400, Ignacio Vazquez-Abrams wrote: > > On Tue, 2005-04-05 at 09:11 +0100, Joe Orton wrote: > > > I expect this was just a braino on someone's part, it should have been > > > Requires not BuildRequires; > > > > No, it was deliberate. It's there for the purpose of allowing the > > package to be built for versions of python other than the primary one, > > e.g., python-2.4 under FC3. It most likely won't get much use, but who's > > to say a similar problem won't show up in the future? > > I don't see how this makes any sense; the dependency on a particular > python ABI is a property of a *binary* package, not a source package. If > you have a package which only builds with python >= 2.4 (is that what > you're saying?), surely it should just BR: python >= 2.4 or similar? Look at these lines in python-amara.spec: %build %{__python}%{pyver} setup.py build This requires /usr/bin/python%{pyver}, which is contained in the same package that provides python-abi = %{pyver}. Since mach would have the same issue looking for /usr/bin/python%{pyver}, the exact form of the BuildRequires is unimportant. -- 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 Tue Apr 5 08:51:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 04:51:59 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112690867.22212.37.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <20050405083502.GA18393@redhat.com> <1112690867.22212.37.camel@ignacio.ignacio.lan> Message-ID: <1112691119.18910.1.camel@cutter> > Look at these lines in python-amara.spec: > > %build > %{__python}%{pyver} setup.py build > > This requires /usr/bin/python%{pyver}, which is contained in the same > package that provides python-abi = %{pyver}. Since mach would have the > same issue looking for /usr/bin/python%{pyver}, the exact form of the > BuildRequires is unimportant. > no, it's not. mach doesn't look at %build. it's just doing buildreqs in advance for the build. when the build is actually occurring it's just running an rpm --rebuild inside the buildroot so this is satisfied. so it's not a problem outside of the BuildRequires. -sv From ivazquez at ivazquez.net Tue Apr 5 08:53:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 04:53:18 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112689646.6556.89.camel@cutter> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> Message-ID: <1112691198.22212.39.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 04:27 -0400, seth vidal wrote: > > No, it was deliberate. It's there for the purpose of allowing the > > package to be built for versions of python other than the primary one, > > e.g., python-2.4 under FC3. It most likely won't get much use, but who's > > to say a similar problem won't show up in the future? > > So wait a sec - you included it so people could build the package for a > version of python that's newer/older than the installed one? > > I think that seems a bit over engineered considering the prominence of > python on the system. You aren't wrong, but who's to say that it's a bad thing? I mean, other than it exposing a minor flaw in mach. Which I am working on, btw. Oh, and where do I log bugs in mach? -- 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 Tue Apr 5 08:56:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 04:56:38 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112691198.22212.39.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> Message-ID: <1112691398.18910.3.camel@cutter> > You aren't wrong, but who's to say that it's a bad thing? I mean, other > than it exposing a minor flaw in mach. Which I am working on, btw. If you're trying to 'fix it' by building the srpm INSIDE the chroot please don't. You're just angling for a world of pain. > Oh, and where do I log bugs in mach? fair question - no good answer at the moment. -sv From ivazquez at ivazquez.net Tue Apr 5 08:57:50 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 04:57:50 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112691119.18910.1.camel@cutter> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <20050405083502.GA18393@redhat.com> <1112690867.22212.37.camel@ignacio.ignacio.lan> <1112691119.18910.1.camel@cutter> Message-ID: <1112691470.22212.42.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 04:51 -0400, seth vidal wrote: > > Look at these lines in python-amara.spec: > > > > %build > > %{__python}%{pyver} setup.py build > > > > This requires /usr/bin/python%{pyver}, which is contained in the same > > package that provides python-abi = %{pyver}. Since mach would have the > > same issue looking for /usr/bin/python%{pyver}, the exact form of the > > BuildRequires is unimportant. > > > > no, it's not. > > mach doesn't look at %build. > > it's just doing buildreqs in advance for the build. Yes, you're correct, we've established that. We're not even really talking about mach here, we're just discussing why putting a BuildRequires on python-abi = %{pyver} makes sense for this package, independent of the build system. -- 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 ivazquez at ivazquez.net Tue Apr 5 09:02:49 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 05:02:49 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112691398.18910.3.camel@cutter> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> <1112691398.18910.3.camel@cutter> Message-ID: <1112691769.22212.44.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 04:56 -0400, seth vidal wrote: > > You aren't wrong, but who's to say that it's a bad thing? I mean, other > > than it exposing a minor flaw in mach. Which I am working on, btw. > > If you're trying to 'fix it' by building the srpm INSIDE the chroot > please don't. You're just angling for a world of pain. Oh, heck no. You don't even need to actually build the SRPM, you just need to evaluate the spec file. -- 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 twaugh at redhat.com Tue Apr 5 09:43:49 2005 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 5 Apr 2005 10:43:49 +0100 Subject: BuildRequires on python-abi In-Reply-To: <20050405081139.GA17951@redhat.com> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> Message-ID: <20050405094349.GM12412@redhat.com> On Tue, Apr 05, 2005 at 09:11:39AM +0100, Joe Orton wrote: > I expect this was just a braino on someone's part, it should have been > Requires not BuildRequires; but the brp-* scripts do it automatically > these days so it should probably be removed from spec files on sight > now. They do? When was that added? Wish I'd known.. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Apr 5 10:14:08 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Apr 2005 12:14:08 +0200 Subject: BuildRequires on python-abi In-Reply-To: <1112691769.22212.44.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> <1112691398.18910.3.camel@cutter> <1112691769.22212.44.camel@ignacio.ignacio.lan> Message-ID: <20050405121408.3be2bde4.bugs.michael@gmx.net> On Tue, 05 Apr 2005 05:02:49 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 04:56 -0400, seth vidal wrote: > > > You aren't wrong, but who's to say that it's a bad thing? I mean, other > > > than it exposing a minor flaw in mach. Which I am working on, btw. > > > > If you're trying to 'fix it' by building the srpm INSIDE the chroot > > please don't. You're just angling for a world of pain. > > Oh, heck no. You don't even need to actually build the SRPM, you just > need to evaluate the spec file. Note that src.rpm packages have dependencies, too, which are queried just like binary rpm dependencies: rpm -qpR foo.src.rpm If you build a src.rpm with "BuildRequires: python-abi = %pyver", you effectively hardcode that build requirement in the src.rpm package. This is bad, not just because mach fetches the BR from there. From ivazquez at ivazquez.net Tue Apr 5 10:44:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 06:44:35 -0400 Subject: BuildRequires on python-abi In-Reply-To: <20050405121408.3be2bde4.bugs.michael@gmx.net> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> <1112691398.18910.3.camel@cutter> <1112691769.22212.44.camel@ignacio.ignacio.lan> <20050405121408.3be2bde4.bugs.michael@gmx.net> Message-ID: <1112697875.22212.48.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 12:14 +0200, Michael Schwendt wrote: > Note that src.rpm packages have dependencies, too, which are queried > just like binary rpm dependencies: rpm -qpR foo.src.rpm Technically true, but it in this case they're purely artificial. The actual BuildRequires can only be gleaned directly from the spec file unfortunately. > If you build a src.rpm with "BuildRequires: python-abi = %pyver", you > effectively hardcode that build requirement in the src.rpm package. > This is bad, not just because mach fetches the BR from there. Please, do tell. -- 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 Tue Apr 5 11:01:38 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 5 Apr 2005 13:01:38 +0200 Subject: BuildRequires on python-abi In-Reply-To: <1112691470.22212.42.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <20050405083502.GA18393@redhat.com> <1112690867.22212.37.camel@ignacio.ignacio.lan> <1112691119.18910.1.camel@cutter> <1112691470.22212.42.camel@ignacio.ignacio.lan> Message-ID: <20050405130138.3f3fdc30.bugs.michael@gmx.net> On Tue, 05 Apr 2005 04:57:50 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 04:51 -0400, seth vidal wrote: > > > Look at these lines in python-amara.spec: > > > > > > %build > > > %{__python}%{pyver} setup.py build > > > > > > This requires /usr/bin/python%{pyver}, which is contained in the same > > > package that provides python-abi = %{pyver}. Since mach would have the > > > same issue looking for /usr/bin/python%{pyver}, the exact form of the > > > BuildRequires is unimportant. > > > > > > > no, it's not. > > > > mach doesn't look at %build. > > > > it's just doing buildreqs in advance for the build. > > Yes, you're correct, we've established that. We're not even really > talking about mach here, we're just discussing why putting a > BuildRequires on python-abi = %{pyver} makes sense for this package, > independent of the build system. It's insufficient and wrong. Looking at python-amara.spec, you do: %{!?pyver: %define pyver %(%{__python} -c 'import sys;print(sys.version[0:3])')} %define mainpyver %(%{__python} -c 'import sys;print(sys.version[0:3])') So, first of all, you depend on %__python, which would be equal to "BuildRequires: %__python". Only later you run %{__python}%{pyver} although you don't buildrequire that binary. From ivazquez at ivazquez.net Tue Apr 5 11:09:11 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 07:09:11 -0400 Subject: BuildRequires on python-abi In-Reply-To: <20050405130138.3f3fdc30.bugs.michael@gmx.net> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <20050405083502.GA18393@redhat.com> <1112690867.22212.37.camel@ignacio.ignacio.lan> <1112691119.18910.1.camel@cutter> <1112691470.22212.42.camel@ignacio.ignacio.lan> <20050405130138.3f3fdc30.bugs.michael@gmx.net> Message-ID: <1112699351.22212.52.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 13:01 +0200, Michael Schwendt wrote: > On Tue, 05 Apr 2005 04:57:50 -0400, Ignacio Vazquez-Abrams wrote: > > > On Tue, 2005-04-05 at 04:51 -0400, seth vidal wrote: > > > mach doesn't look at %build. > > > > > > it's just doing buildreqs in advance for the build. > > > > Yes, you're correct, we've established that. We're not even really > > talking about mach here, we're just discussing why putting a > > BuildRequires on python-abi = %{pyver} makes sense for this package, > > independent of the build system. > > It's insufficient and wrong. Looking at python-amara.spec, you do: > > %{!?pyver: %define pyver %(%{__python} -c 'import sys;print(sys.version[0:3])')} > %define mainpyver %(%{__python} -c 'import sys;print(sys.version[0:3])') > > So, first of all, you depend on %__python, which would be equal to > "BuildRequires: %__python". Fair enough. I forgot that one. > Only later you run %{__python}%{pyver} although you don't buildrequire > that binary. Yes, you're correct. BuildRequiring that binary would be the correct approach, although the current BR pulls in that binary anyways, and the new BR wouldn't mitigate the mach problem. -- 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 ivazquez at ivazquez.net Tue Apr 5 11:12:02 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 07:12:02 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112688411.6556.82.camel@cutter> References: <1112685473.6556.64.camel@cutter> <1112686897.22212.25.camel@ignacio.ignacio.lan> <1112687261.6556.75.camel@cutter> <1112687975.22212.29.camel@ignacio.ignacio.lan> <1112688411.6556.82.camel@cutter> Message-ID: <1112699522.22212.54.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 04:06 -0400, seth vidal wrote: > - mach reads the buildreqs from the srpms - and tries to satisfy them > - it also parses the spec file and tries to satisfy the reqs in there - > mostly looking for ifdef's, though, iirc. I can't seem to get my head wrapped around mach atm so I'm going to pull the version code for now. I will keep working on the issue part-time though. -- 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 ville.skytta at iki.fi Tue Apr 5 15:04:41 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 05 Apr 2005 18:04:41 +0300 Subject: BuildRequires on python-abi In-Reply-To: <20050405094349.GM12412@redhat.com> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <20050405094349.GM12412@redhat.com> Message-ID: <1112713481.22818.32.camel@bobcat.mine.nu> On Tue, 2005-04-05 at 10:43 +0100, Tim Waugh wrote: > On Tue, Apr 05, 2005 at 09:11:39AM +0100, Joe Orton wrote: > > > I expect this was just a braino on someone's part, it should have been > > Requires not BuildRequires; but the brp-* scripts do it automatically > > these days so it should probably be removed from spec files on sight > > now. > > They do? When was that added? In post-FC3 Rawhide. From riel at redhat.com Tue Apr 5 15:59:46 2005 From: riel at redhat.com (Rik van Riel) Date: Tue, 5 Apr 2005 11:59:46 -0400 (EDT) Subject: RFD: kernel-devel package improvements In-Reply-To: <1112590198.14994.5.camel@thl.ct.heise.de> References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu> <1112188228.27816.62.camel@anu.eridu> <1112561850.24368.104.camel@bobcat.mine.nu> <1112590198.14994.5.camel@thl.ct.heise.de> Message-ID: On Mon, 4 Apr 2005, Thorsten Leemhuis wrote: > Am Sonntag, den 03.04.2005, 23:45 -0400 schrieb Rik van Riel: > > I am inclined to just not fix this - how important is it to > > build the external kernel modules for i586 ? > Yes, probably nearly nobody needs a ati or a nvidia driver for a i586 > machine (but we provide them on livna). But ntfs and/or GFS (or insert > something that else that may arise in the future) might me of interest. Note that if you really want to build kernel module RPMs for both i586 and i686 on the same system, you can always install the different kernel-devel packages into their own chroot environments. This is pretty much a corner case and probably not worth hacking up RPM over... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From pjones at redhat.com Tue Apr 5 15:59:52 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 05 Apr 2005 11:59:52 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112685473.6556.64.camel@cutter> References: <1112685473.6556.64.camel@cutter> Message-ID: <1112716792.2488.4.camel@localhost.localdomain> On Tue, 2005-04-05 at 03:17 -0400, seth vidal wrote: > Hey folks, > I was looking at some packages with: > > BuildRequires: python-abi = %{pyver} > > when this is in an srpm, built on fc3 it comes out as python-abi = 2.3 > when you try to rebuild this srpm on rawhide it is impossible to provide > the buildreq b/c nothing provides python-abi = 2.3. > > So I was thinking - wouldn't it make sense for a buildrequires on > python-abi to be >= %{pyver}? How exactly is that any better than "BuildRequires: python"? If there's some specific version you know a package _can't_ be built against, then adding something like this makes sense. I'm just not sure it's worth the trouble for the normal case. It's just more data, not more useful data. -- Peter From notting at redhat.com Tue Apr 5 16:34:47 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 5 Apr 2005 12:34:47 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112685473.6556.64.camel@cutter> References: <1112685473.6556.64.camel@cutter> Message-ID: <20050405163447.GG3932@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > Hey folks, > I was looking at some packages with: > > BuildRequires: python-abi = %{pyver} This seems wrong to have in *any* case. What version of python a module requires to build seems like it would be tied specifically to why python features it uses. For example, python-frobozz uses no new python features, and would need; BuildRequires: python while python-mumblefrotz uses some random new thing, and would need: BuildRequires: python-abi = 2.4 I don't think the build reuqires should be autogenerated at all. Bill From mharris at www.linux.org.uk Tue Apr 5 16:51:28 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Tue, 05 Apr 2005 12:51:28 -0400 Subject: RunWM is about to go bye bye Message-ID: <4252C210.1070703@www.linux.org.uk> RunWM is an ancient and horrendous script that was once used to kill baby seals. Recently, we have been contacted by PETA about this, and in an effort to comply with federal wildlife regulations, we are planning on removing RunWM. I've done a preliminary search, and have not been able to find any packages that depend on this script explicitly in Core. It is possible something else may explicitly require it, but if that is true, it is time to fix everything to NOT require it. If you know of any package in Core that requires RunWM which I'm not seeing, please speak now. Outside of Core, let the maintainer of the software know that RunWM is going away. THINK OF THE CUTE BABY SEALS! From pjones at redhat.com Tue Apr 5 18:56:42 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 05 Apr 2005 14:56:42 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112691198.22212.39.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> Message-ID: <1112727402.2488.14.camel@localhost.localdomain> On Tue, 2005-04-05 at 04:53 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 04:27 -0400, seth vidal wrote: > > > No, it was deliberate. It's there for the purpose of allowing the > > > package to be built for versions of python other than the primary one, > > > e.g., python-2.4 under FC3. It most likely won't get much use, but who's > > > to say a similar problem won't show up in the future? > > > > So wait a sec - you included it so people could build the package for a > > version of python that's newer/older than the installed one? > > > > I think that seems a bit over engineered considering the prominence of > > python on the system. > > You aren't wrong, but who's to say that it's a bad thing? I mean, other > than it exposing a minor flaw in mach. Which I am working on, btw. Well, you are encouraging people to put themselves into a situation where they've got two ABI-incompatible packages with the same NVREA, and different deps. That's a very bad thing; if you're in the scenario where you've got multiple packages, indistinguishable by NVREA, it means you *can't* do server-side dependency resolution. So it screws remote management software completely. -- Peter From ivazquez at ivazquez.net Tue Apr 5 19:01:32 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 05 Apr 2005 15:01:32 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112727402.2488.14.camel@localhost.localdomain> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> <1112727402.2488.14.camel@localhost.localdomain> Message-ID: <1112727693.22212.72.camel@ignacio.ignacio.lan> On Tue, 2005-04-05 at 14:56 -0400, Peter Jones wrote: > Well, you are encouraging people to put themselves into a situation > where they've got two ABI-incompatible packages with the same NVREA, and > different deps. Except for the fact that the spec file was written in such a way that the Name would be different, so NEVRA uniqueness would be preserved. -- 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 Tue Apr 5 19:04:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 15:04:10 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112727693.22212.72.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> <1112727402.2488.14.camel@localhost.localdomain> <1112727693.22212.72.camel@ignacio.ignacio.lan> Message-ID: <1112727850.20867.102.camel@cutter> On Tue, 2005-04-05 at 15:01 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 14:56 -0400, Peter Jones wrote: > > Well, you are encouraging people to put themselves into a situation > > where they've got two ABI-incompatible packages with the same NVREA, and > > different deps. > > Except for the fact that the spec file was written in such a way that > the Name would be different, so NEVRA uniqueness would be preserved. I think we should probably put it into the guidelines that the spec file shouldn't allow the package NAME to change as that breaks looking for it in cvs and in bugzilla. -sv From pjones at redhat.com Tue Apr 5 19:23:40 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 05 Apr 2005 15:23:40 -0400 Subject: BuildRequires on python-abi In-Reply-To: <20050405083502.GA18393@redhat.com> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <20050405083502.GA18393@redhat.com> Message-ID: <1112729020.2488.37.camel@localhost.localdomain> On Tue, 2005-04-05 at 09:35 +0100, Joe Orton wrote: > On Tue, Apr 05, 2005 at 04:22:35AM -0400, Ignacio Vazquez-Abrams wrote: > > On Tue, 2005-04-05 at 09:11 +0100, Joe Orton wrote: > > > I expect this was just a braino on someone's part, it should have been > > > Requires not BuildRequires; > > > > No, it was deliberate. It's there for the purpose of allowing the > > package to be built for versions of python other than the primary one, > > e.g., python-2.4 under FC3. It most likely won't get much use, but who's > > to say a similar problem won't show up in the future? > > I don't see how this makes any sense; the dependency on a particular > python ABI is a property of a *binary* package, not a source package. If > you have a package which only builds with python >= 2.4 (is that what > you're saying?), surely it should just BR: python >= 2.4 or similar? The purpose of BuildReq's isn't to say "this won't build on an earlier system than the one I built on". BuildRequires are there to help maintain the expectation of a repeatable build. That's the point. If the build fails or succeeds, the point is still that the if you repeat it, you'll get the same result. BuildRequires are there to help you repeat the same thing. If we're making requirements by looking around in the build environment, they need to specify that the requirement guarantees the *same* build environment. The right way to use them isn't to express "I know $FOO-1.0 won't build with an older version of $BAR than 1.1" -- though that can be useful in a pinch, it's really a bit of a kludge. The right expression is "$FOO-1.0 is to be built with $BAR-1.1". This allows an NVREA to have a meaning to depsolvers and such, so they don't have to reread a package every time -- they can cache metadata instead. We certainly shouldn't be encouraging people to rebuild a .src.rpm with a newer rpm or buildroot -- those result in different deps in the resulting packages, which means at the very least RELEASE should be changed. If we're going to have buildreq's such as this, they should be "=", not ">=". And if it's only "=", then it's completely pointless, unless it's a dep rpm won't already add to the .src.rpm. So we're just as well off without the line, IMHO. -- Peter From pjones at redhat.com Tue Apr 5 19:27:56 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 05 Apr 2005 15:27:56 -0400 Subject: BuildRequires on python-abi In-Reply-To: <1112727693.22212.72.camel@ignacio.ignacio.lan> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> <1112727402.2488.14.camel@localhost.localdomain> <1112727693.22212.72.camel@ignacio.ignacio.lan> Message-ID: <1112729276.2488.45.camel@localhost.localdomain> On Tue, 2005-04-05 at 15:01 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2005-04-05 at 14:56 -0400, Peter Jones wrote: > > Well, you are encouraging people to put themselves into a situation > > where they've got two ABI-incompatible packages with the same NVREA, and > > different deps. > > Except for the fact that the spec file was written in such a way that > the Name would be different, so NEVRA uniqueness would be preserved. "the spec file"? Seth's question was: On Tue, 2005-04-05 at 03:17 -0400, seth vidal wrote: > Hey folks, > I was looking at some packages with: > > BuildRequires: python-abi = %{pyver} > > when this is in an srpm, built on fc3 it comes out as python-abi = 2.3 > when you try to rebuild this srpm on rawhide it is impossible to provide > the buildreq b/c nothing provides python-abi = 2.3. > > So I was thinking - wouldn't it make sense for a buildrequires on > python-abi to be >= %{pyver}? He's not asking about any specific package, he's asking about such deps in general. And in general, spec files aren't written so the package name changes when you rebuild with some other build environment. (and they shouldn't be, that's a really sick hack anyway) -- Peter From tcallawa at redhat.com Wed Apr 6 17:33:03 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 06 Apr 2005 12:33:03 -0500 Subject: BuildRequires on python-abi In-Reply-To: <1112727850.20867.102.camel@cutter> References: <1112685473.6556.64.camel@cutter> <20050405081139.GA17951@redhat.com> <1112689355.22212.32.camel@ignacio.ignacio.lan> <1112689646.6556.89.camel@cutter> <1112691198.22212.39.camel@ignacio.ignacio.lan> <1112727402.2488.14.camel@localhost.localdomain> <1112727693.22212.72.camel@ignacio.ignacio.lan> <1112727850.20867.102.camel@cutter> Message-ID: <1112808783.4899.32.camel@localhost.localdomain> On Tue, 2005-04-05 at 15:04 -0400, seth vidal wrote: > On Tue, 2005-04-05 at 15:01 -0400, Ignacio Vazquez-Abrams wrote: > > On Tue, 2005-04-05 at 14:56 -0400, Peter Jones wrote: > > > Well, you are encouraging people to put themselves into a situation > > > where they've got two ABI-incompatible packages with the same NVREA, and > > > different deps. > > > > Except for the fact that the spec file was written in such a way that > > the Name would be different, so NEVRA uniqueness would be preserved. > > I think we should probably put it into the guidelines that the spec file > shouldn't allow the package NAME to change as that breaks looking for it > in cvs and in bugzilla. Agreed. 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 wtogami at redhat.com Thu Apr 7 11:01:56 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 07 Apr 2005 01:01:56 -1000 Subject: BuildRequires on python-abi In-Reply-To: <1112688411.6556.82.camel@cutter> References: <1112685473.6556.64.camel@cutter> <1112686897.22212.25.camel@ignacio.ignacio.lan> <1112687261.6556.75.camel@cutter> <1112687975.22212.29.camel@ignacio.ignacio.lan> <1112688411.6556.82.camel@cutter> Message-ID: <42551324.4030809@redhat.com> seth vidal wrote: > To give you a bit more info: > - mach reads the buildreqs from the srpms - and tries to satisfy them This step is just plain wrong. This is prone to breaking in several scenarios including this one. We need deps to be parsed only from a fresh spec, parsed within a minimal buildroot of a target distro. http://enrico-scholz.de/fedora.us-build/files/ IIRC Enrico's wrappers around mach used in the fedora.us buildsystem had two passes for spec parsing to pull in deps. This older implementation is not ideal because it avoided rpmlib. But this multiple pass approach using rpmlib is exactly the right idea. First pass allows it to determine BuildRequires to put into the buildroot. Then after those BuildRequires are installed, the second pass happens during rpmbuild itself, where the actual values from stuff executed in %() are filled in the resulting packages. The deps in the binary RPMS are the only important deps. The deps in the SRPM output are unimportant and should not influence anything in the future. Warren Togami wtogami at redhat.com From gafton at redhat.com Fri Apr 8 18:25:15 2005 From: gafton at redhat.com (Cristian Gafton) Date: Fri, 8 Apr 2005 14:25:15 -0400 (EDT) Subject: BuildRequires on python-abi In-Reply-To: <1112688411.6556.82.camel@cutter> References: <1112685473.6556.64.camel@cutter> <1112686897.22212.25.camel@ignacio.ignacio.lan> <1112687261.6556.75.camel@cutter> <1112687975.22212.29.camel@ignacio.ignacio.lan> <1112688411.6556.82.camel@cutter> Message-ID: On Tue, 5 Apr 2005, seth vidal wrote: > To give you a bit more info: > - mach reads the buildreqs from the srpms - and tries to satisfy them > - it also parses the spec file and tries to satisfy the reqs in there - > mostly looking for ifdef's, though, iirc. That's not quite right, though. What you really want is to unpack/extract the spec file and then get going with "rpm -q --specfile ..." to get the data you need. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From ivazquez at ivazquez.net Fri Apr 8 19:29:55 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 08 Apr 2005 15:29:55 -0400 Subject: BuildRequires on python-abi In-Reply-To: References: <1112685473.6556.64.camel@cutter> <1112686897.22212.25.camel@ignacio.ignacio.lan> <1112687261.6556.75.camel@cutter> <1112687975.22212.29.camel@ignacio.ignacio.lan> <1112688411.6556.82.camel@cutter> Message-ID: <1112988595.8034.15.camel@ignacio.ignacio.lan> On Fri, 2005-04-08 at 14:25 -0400, Cristian Gafton wrote: > On Tue, 5 Apr 2005, seth vidal wrote: > > > To give you a bit more info: > > - mach reads the buildreqs from the srpms - and tries to satisfy them > > - it also parses the spec file and tries to satisfy the reqs in there - > > mostly looking for ifdef's, though, iirc. > > That's not quite right, though. > > What you really want is to unpack/extract the spec file and then get > going with "rpm -q --specfile ..." to get the data you need. This is exactly the fix I was/am hoping to implement. -- 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 snickell at redhat.com Mon Apr 11 19:54:30 2005 From: snickell at redhat.com (Seth Nickell) Date: Mon, 11 Apr 2005 15:54:30 -0400 Subject: RunWM is about to go bye bye In-Reply-To: <4252C210.1070703@www.linux.org.uk> References: <4252C210.1070703@www.linux.org.uk> Message-ID: <1113249270.19695.2.camel@localhost.localdomain> ha ha ha On Tue, 2005-04-05 at 12:51 -0400, Mike A. Harris wrote: > RunWM is an ancient and horrendous script that was once used > to kill baby seals. Recently, we have been contacted by PETA > about this, and in an effort to comply with federal wildlife > regulations, we are planning on removing RunWM. > > I've done a preliminary search, and have not been able to > find any packages that depend on this script explicitly in > Core. It is possible something else may explicitly require > it, but if that is true, it is time to fix everything to NOT > require it. > > If you know of any package in Core that requires RunWM which > I'm not seeing, please speak now. Outside of Core, let the > maintainer of the software know that RunWM is going away. > > THINK OF THE CUTE BABY SEALS! > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 14 10:51:24 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Apr 2005 12:51:24 +0200 Subject: STR working out of the box In-Reply-To: <1112197590.3952.2.camel@daxter.boston.redhat.com> References: <1110698182.8327.69.camel@daxter.boston.redhat.com> <20050314170448.GE10338@nostromo.devel.redhat.com> <1110869044.14869.201.camel@daxter.boston.redhat.com> <20050315184935.GF12363@nostromo.devel.redhat.com> <1112192881.1531.87.camel@bnocera.surrey.redhat.com> <1112197590.3952.2.camel@daxter.boston.redhat.com> Message-ID: <20050414125124.2cfdbd18@python2> David Zeuthen wrote : > Btw, I've got an update of all this (removing the white lists, moving > what action to do into battstat applet) that I will post in a few days > so stay tuned. Any news? I've just got a new Dell X1 laptop, installed FC4 Test2, and got the usual disappointments : Native screen resolution impossible to configure (a weirdo 1280x768, but the 1680x1050 I have on my i8600 can't be GUI-configured either), and non-existing suspend. So I'm desperately wanting to try out suspend related feature to help get FC4 to "do the right thing". Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 3.12 2.63 1.44 From mattdm at mattdm.org Thu Apr 14 16:18:15 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 14 Apr 2005 12:18:15 -0400 Subject: Fedora Legacy, and What's Happening to *Your* FC2 Bugs.... Message-ID: <20050414161815.GA15677@jadzia.bu.edu> As I'm sure everyone knows -- and all maintainers not involved with Fedora Legacy are probably relieved by -- Fedora Core 2 is now "transferred" to the Fedora Legacy Project. Maybe you've already seen my posts on the fedora-legacy list, or by now, the LWN article about this. Having Fedora Legacy succeed is important to me, and I believe vital to the long-term survival of the Fedora Project and of the Fedora/RHEL ecosystem as a whole [1]. One part of making this transfer credible is dealing with the left-open Fedora Core 2 bugs. If they all remain as-is, the Bugzilla will eventually become a desolate wasteland of abandoned issues and user and developer frustration [2]. I've already examined and transferred all bugs marked with a severity of "security". For the rest, I propose to mark ALL still-open FC2 bugs as "NEEDINFO", with the following message: Fedora Core 2 is now maintained for security updates only by the Fedora Legacy project. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC4 test release, reopen and change the version to match. Then, in one month, all FC2 bugs still in the NEEDINFO state would be marked as RESOLVED:WONTFIX, again with a comment similar to the above. There are about 1200 FC2 bugs in open state right now; of those, over a third are assigned to the kernel. Dave Jones has already indicated that he's okay with this basic approach (in fact, if I understand correctly, he'd prefer to jump straight to WONTFIX). While I'm naming names, Bill Nottingham, notes that some developers use bugzilla.redhat.com as the effectively upstream bugzilla for some packages, and that shutting everything down might not be what's wanted. That's why I propose the two-step approach above. Also, I'll put myself on the CC list of every single one of those bugs and deal with any fallout from my actions. Before I actually go ahead and do anything though, I'd appreciate hearing what other people think is the right thing to do in this situation. Thanks! .......................................................................... Footnotes: 1. I have some further thoughts on this that I'm developing as a response to Michael Tiemann's FUDCon1 talk -- more on this later sometime. 2. I know some people feel that it's that way already. Okay then, this is part of an attempt to salvage it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davidz at redhat.com Thu Apr 14 17:29:42 2005 From: davidz at redhat.com (David Zeuthen) Date: Thu, 14 Apr 2005 13:29:42 -0400 Subject: STR working out of the box In-Reply-To: <20050414125124.2cfdbd18@python2> References: <1110698182.8327.69.camel@daxter.boston.redhat.com> <20050314170448.GE10338@nostromo.devel.redhat.com> <1110869044.14869.201.camel@daxter.boston.redhat.com> <20050315184935.GF12363@nostromo.devel.redhat.com> <1112192881.1531.87.camel@bnocera.surrey.redhat.com> <1112197590.3952.2.camel@daxter.boston.redhat.com> <20050414125124.2cfdbd18@python2> Message-ID: <1113499782.3811.1.camel@daxter.boston.redhat.com> On Thu, 2005-04-14 at 12:51 +0200, Matthias Saou wrote: > David Zeuthen wrote : > > > Btw, I've got an update of all this (removing the white lists, moving > > what action to do into battstat applet) that I will post in a few days > > so stay tuned. > > Any news? I've just got a new Dell X1 laptop, installed FC4 Test2, and got > the usual disappointments : Native screen resolution impossible to > configure (a weirdo 1280x768, but the 1680x1050 I have on my i8600 can't > be GUI-configured either), and non-existing suspend. > > So I'm desperately wanting to try out suspend related feature to help get > FC4 to "do the right thing". Did you try the scripts in the RPM that I posted about a month ago? The aim is to move these scripts into the new pm-utils package that notting put in Rawhide yesterday. I've also got an almost finished patch for gnome-applets that enables the battstat applet to take advantage of these scripts via consolehelper. David From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Apr 14 18:53:27 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 14 Apr 2005 20:53:27 +0200 Subject: STR working out of the box In-Reply-To: <1113499782.3811.1.camel@daxter.boston.redhat.com> References: <1110698182.8327.69.camel@daxter.boston.redhat.com> <20050314170448.GE10338@nostromo.devel.redhat.com> <1110869044.14869.201.camel@daxter.boston.redhat.com> <20050315184935.GF12363@nostromo.devel.redhat.com> <1112192881.1531.87.camel@bnocera.surrey.redhat.com> <1112197590.3952.2.camel@daxter.boston.redhat.com> <20050414125124.2cfdbd18@python2> <1113499782.3811.1.camel@daxter.boston.redhat.com> Message-ID: <20050414205327.43e6c6e6@python2> David Zeuthen wrote : > > So I'm desperately wanting to try out suspend related feature to help get > > FC4 to "do the right thing". > > Did you try the scripts in the RPM that I posted about a month ago? The > aim is to move these scripts into the new pm-utils package that notting > put in Rawhide yesterday. I've been fighting with suspend/resume most of the afternoon to no avail. It's the first Intel chipset I try it on, and just can't seem to get the display to turn back on after resume. I already installed that new pm- utils too, hoping it would already include scripts and improvements, but saw that it (for now) only had the tools. > I've also got an almost finished patch for gnome-applets that enables > the battstat applet to take advantage of these scripts via > consolehelper. Sounds neat! I also saw today that the default suspend command in that applet was still for APM... it was time to change that for sure. I'll continue fighting against that laptop... I sure am grateful journaled filesystems exists! ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.15 0.17 0.21 From wtogami at redhat.com Sun Apr 17 10:12:40 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Apr 2005 00:12:40 -1000 Subject: CVS blew up for iptstate Message-ID: <42623698.1010705@redhat.com> I don't know how CVS came to be missing the devel branch. [warren at ibmlaptop iptstate]$ ls common CVS FC-1 FC-2 import.log Makefile RHL-8 RHL-9 [warren at ibmlaptop iptstate]$ cd common/ [warren at ibmlaptop common]$ ls CVS cvs-import.sh Makefile Makefile.common tobuild [warren at ibmlaptop common]$ ./cvs-import.sh /tmp/iptstate-1.4-1.fc3.src.rpm Checking out the modules file... Module 'iptstate' already exists... Checking out module: 'iptstate' Unpacking source package: iptstate-1.4-1.fc3.src.rpm... find: devel: No such file or directory ./cvs-import.sh: line 283: devel/sources.new: No such file or directory ./cvs-import.sh: line 284: devel/.cvsignore.new: No such file or directory mv: cannot move `tmpVL7603/iptstate-1.4-optflags.patch' to `devel/iptstate-1.4-optflags.patch': No such file or directory ./cvs-import.sh: line 310: pushd: devel: No such file or directory cvs add: nothing known about iptstate-1.4-optflags.patch A iptstate-1.4-optflags.patch ./cvs-import.sh: line 330: popd: directory stack empty mv: cannot move `tmpVL7603/iptstate-1.4.tar.bz2' to `devel/iptstate-1.4.tar.bz2': No such file or directory ./cvs-import.sh: line 310: pushd: devel: No such file or directory L iptstate-1.4.tar.bz2 ./cvs-import.sh: line 330: popd: directory stack empty mv: cannot move `tmpVL7603/iptstate.spec' to `devel/iptstate.spec': No such file or directory ./cvs-import.sh: line 310: pushd: devel: No such file or directory cvs add: nothing known about iptstate.spec A iptstate.spec ./cvs-import.sh: line 330: popd: directory stack empty ./cvs-import.sh: line 333: pushd: devel: No such file or directory mv: cannot stat `sources.new': No such file or directory mv: cannot stat `.cvsignore.new': No such file or directory make: *** No rule to make target `upload'. Stop. ERROR: Uploading the source tarballs failed! "mkbranch -s FC-2 devel iptstate" also seems to fail on the server. [wtogami at cvs-int wtogami]$ /cvs/extras/CVSROOT/mkbranch -s FC-2 devel iptstate Creating new module branch 'devel' for 'iptstate' from branch 'FC-2'... ERROR: Tag devel-split is not in a valid tag format cvs rtag: Pre-tag check failed cvs [rtag aborted]: correct the above errors first! ERROR: Branch split tag for iptstate/FC-2 could not be created Any suggestions? Warren Togami wtogami at redhat.com From wtogami at redhat.com Sun Apr 17 10:22:06 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Apr 2005 00:22:06 -1000 Subject: Fedora Legacy, and What's Happening to *Your* FC2 Bugs.... In-Reply-To: <20050414161815.GA15677@jadzia.bu.edu> References: <20050414161815.GA15677@jadzia.bu.edu> Message-ID: <426238CE.6060303@redhat.com> NEEDINFO on everything sounds like a good plan. Give the bug submitters a chance to say "this is still an issue in devel (FC4)" and move the bug there. After a while in NEEDINFO just close it due to lack of activity. That is more than fair. Warren Togami wtogami at redhat.com From gafton at redhat.com Sun Apr 17 10:32:53 2005 From: gafton at redhat.com (Cristian Gafton) Date: Sun, 17 Apr 2005 06:32:53 -0400 (EDT) Subject: CVS blew up for iptstate In-Reply-To: <42623698.1010705@redhat.com> References: <42623698.1010705@redhat.com> Message-ID: On Sun, 17 Apr 2005, Warren Togami wrote: > I don't know how CVS came to be missing the devel branch. Let's see... How could that be... Maybe Warren deleted it himself? .bash_history:for package in MozillaThunderbird Pyrex acme alsa-driver alsa-lib alsa-oss alsa-utils autoconf bitstream-vera-fonts cscope devhelp dia dvd+rw-tools evolution-connector firefox flac gimp2 gkrellm gnome-alsamixer gnutls gob2 gtkspell hardlink iptstate k3b libdv libgcrypt libgpg-error libidn libsilc libtheora nano nmap speex subversion swig xchat xrestop yum stickynotes_applet themes-meta-nuvola velocity-filemanager ximian-wallpapers; do rm -rf $package/devel/; done > [warren at ibmlaptop common]$ ./cvs-import.sh /tmp/iptstate-1.4-1.fc3.src.rpm That's not gonna work, because you are asking cvs-import to work in the devel/ branch, which does not exist. YOU CAN NOT DO THAT. > "mkbranch -s FC-2 devel iptstate" also seems to fail on the server. You also CAN NOT DO THAT. The devel branch is special and can not be mkbranch-ed back (actually, it could, it just never made sense to pay attention to this remote possibility that will ever be needed...) > Any suggestions? Well, you deleted the branch some time ago. What would you like to have happen now? Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From wtogami at redhat.com Sun Apr 17 10:37:23 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 17 Apr 2005 00:37:23 -1000 Subject: CVS blew up for iptstate In-Reply-To: References: <42623698.1010705@redhat.com> Message-ID: <42623C63.3070304@redhat.com> Cristian Gafton wrote: > On Sun, 17 Apr 2005, Warren Togami wrote: > >> I don't know how CVS came to be missing the devel branch. > > > Let's see... How could that be... Maybe Warren deleted it himself? I'm too tired and wasn't thinking straight, this was a false alarm. It is still in FC4. It was among the batch of stuff in Extras CVS where I deleted the devel branch because it was put into Core. While this is a false alarm, we may be screwed in the future if something in Core goes back into Extras and the devel branch was blown away before... If killing the devel branch was a bad idea, then what else should we do? Warren Togami wtogami at redhat.com From gafton at redhat.com Sun Apr 17 10:56:03 2005 From: gafton at redhat.com (Cristian Gafton) Date: Sun, 17 Apr 2005 06:56:03 -0400 (EDT) Subject: CVS blew up for iptstate In-Reply-To: <42623C63.3070304@redhat.com> References: <42623698.1010705@redhat.com> <42623C63.3070304@redhat.com> Message-ID: On Sun, 17 Apr 2005, Warren Togami wrote: > While this is a false alarm, we may be screwed in the future if something in > Core goes back into Extras and the devel branch was blown away before... If > killing the devel branch was a bad idea, then what else should we do? I did not say that killing the devel branch was a bad idea. I said that creating it back is more complex than creating a regular branch. And at this moment it is a fairly laborious process because the tools do not support it - since it has never been needed. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From mattdm at mattdm.org Mon Apr 18 03:07:21 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 17 Apr 2005 23:07:21 -0400 Subject: Fedora Legacy, and What's Happening to *Your* FC2 Bugs.... In-Reply-To: <426238CE.6060303@redhat.com> References: <20050414161815.GA15677@jadzia.bu.edu> <426238CE.6060303@redhat.com> Message-ID: <20050418030721.GA4636@jadzia.bu.edu> On Sun, Apr 17, 2005 at 12:22:06AM -1000, Warren Togami wrote: > NEEDINFO on everything sounds like a good plan. Give the bug submitters > a chance to say "this is still an issue in devel (FC4)" and move the bug > there. After a while in NEEDINFO just close it due to lack of activity. > That is more than fair. Thanks for the feedback, Warren, and much thanks to Dave Jones, who has dealt with all of his kernel bugs, leaving exactly 700 fc2 bugs in open states. Anyone else have any input? I would like to proceed with this plan this week. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mharris at www.linux.org.uk Tue Apr 19 11:00:09 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Tue, 19 Apr 2005 07:00:09 -0400 Subject: Fedora Legacy, and What's Happening to *Your* FC2 Bugs.... In-Reply-To: <20050414161815.GA15677@jadzia.bu.edu> References: <20050414161815.GA15677@jadzia.bu.edu> Message-ID: <4264E4B9.8080201@www.linux.org.uk> Matthew Miller wrote: > As I'm sure everyone knows -- and all maintainers not involved with > Fedora Legacy are probably relieved by -- Fedora Core 2 is now > "transferred" to the Fedora Legacy Project. > > Maybe you've already seen my posts on the fedora-legacy list, or by > now, the LWN article about this. Having Fedora Legacy succeed is > important to me, and I believe vital to the long-term survival of the > Fedora Project and of the Fedora/RHEL ecosystem as a whole [1]. One > part of making this transfer credible is dealing with the left-open > Fedora Core 2 bugs. If they all remain as-is, the Bugzilla will > eventually become a desolate wasteland of abandoned issues and user and > developer frustration [2]. I've been doing massive X bug triage for the last 3 weeks, and have mostly cleaned out all FC2 bugs related to X. I'll be continuing to clean out various ancient X bugs over the next little while also, so we'll end up with no more FC2 bugs very shortly (if there are any left) for X, xterm, and other things owned by xgl-maint. Basically, you can just ignore xgl-maint bugs and they'll take care of themselves very soon if they haven't been already. HTH From jorton at redhat.com Tue Apr 19 13:57:16 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 19 Apr 2005 14:57:16 +0100 Subject: Fedora Legacy, and What's Happening to *Your* FC2 Bugs.... In-Reply-To: <20050418030721.GA4636@jadzia.bu.edu> References: <20050414161815.GA15677@jadzia.bu.edu> <426238CE.6060303@redhat.com> <20050418030721.GA4636@jadzia.bu.edu> Message-ID: <20050419135716.GA4237@redhat.com> On Sun, Apr 17, 2005 at 11:07:21PM -0400, Matthew Miller wrote: > On Sun, Apr 17, 2005 at 12:22:06AM -1000, Warren Togami wrote: > > NEEDINFO on everything sounds like a good plan. Give the bug submitters > > a chance to say "this is still an issue in devel (FC4)" and move the bug > > there. After a while in NEEDINFO just close it due to lack of activity. > > That is more than fair. > > Thanks for the feedback, Warren, and much thanks to Dave Jones, who has > dealt with all of his kernel bugs, leaving exactly 700 fc2 bugs in open > states. Anyone else have any input? I would like to proceed with this plan > this week. The plan seems great to me, thanks for dealing with this. About the wording: If it is not a security issue and hasn't been resolved in the current FC4 test release, reopen and change the version to match. this seems to imply that we don't have a responsibility to fix FC3 bugs, which I don't agree with! I'd prefer it were reworded to say something like: "...hasn't been resolved in the current FC3 updates or the FC4 test release, ..." Regards, joe From jdennis at redhat.com Tue Apr 19 20:07:02 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 19 Apr 2005 16:07:02 -0400 Subject: where 'o where to store certificates and keys Message-ID: <1113941222.10777.58.camel@localhost.localdomain> At the moment we have an ad hoc approach to where we store ssl certificates and other keys. The openssl package installs into /usr/share/ssl and some packages store their keys in /usr/share/ssl/certs/{public,private} because of the lack of anything better and its the closest thing we have to a standard location. Other packages (e.g. httpd) store their keys in their own directories. There are three major reasons to create a new uniform location, and this is a proposal to do so: 1) /usr/share is designed to be NFS mounted and shared. Private certificates and keys really should not be located by default in a directory visible to many machines on the network. /usr/share is an insecure location. 2) SELinux labeling and policy authorship would be much easier and more robust if we collected certificates and keys in one place and label those files appropriately. 3) Certificates and keys are not a property of the openssl package, there should be a package neutral location in the spirit of FHS to locate all certificate and key files which can be shared by all packages. Someplace in /etc seems ideal. Proposal: the filesystem rpm creates the following 3 new directories /etc/keys /etc/keys/public /etc/keys/private Individual applications can make use of these directories in whatever fashion they desire, as long as the files they install there are certificates or keys of any form. They set their own permissions and ownerships. I know this has been debated before, be we've got to make a decision and move forward (in part because this is now gating some work on my plate :-). I've had a hallway conversation with Nalin and Dan Walsh and it was agreed this was the most palatable option at the moment (not ideal, but a workable solution). ACK's or NCK's please! -- John Dennis From skvidal at phy.duke.edu Tue Apr 19 20:17:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 19 Apr 2005 16:17:35 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <1113941222.10777.58.camel@localhost.localdomain> References: <1113941222.10777.58.camel@localhost.localdomain> Message-ID: <1113941855.15629.31.camel@cutter> > Proposal: the filesystem rpm creates the following 3 new directories > > /etc/keys > /etc/keys/public > /etc/keys/private > > ACK's or NCK's please! ACK /etc/keys is fine - I've been using /etc/ssl for years now for precisely the reasons you list - and it makes backups easier. switching to /etc/keys is fine by me. -sv From dcbw at redhat.com Tue Apr 19 20:19:55 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 19 Apr 2005 16:19:55 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <1113941222.10777.58.camel@localhost.localdomain> References: <1113941222.10777.58.camel@localhost.localdomain> Message-ID: <1113941995.31062.5.camel@dcbw.boston.redhat.com> On Tue, 2005-04-19 at 16:07 -0400, John Dennis wrote: > 3) Certificates and keys are not a property of the openssl package, > there should be a package neutral location in the spirit of FHS to > locate all certificate and key files which can be shared by all > packages. Someplace in /etc seems ideal. > > Proposal: the filesystem rpm creates the following 3 new directories > > /etc/keys > /etc/keys/public > /etc/keys/private > > Individual applications can make use of these directories in whatever > fashion they desire, as long as the files they install there are > certificates or keys of any form. They set their own permissions and > ownerships. +1 from me. From a desktop perspective, we need _one_ place to store user certs and keys. For example, in the future when NetworkManager supports 802.1x and wireless authentication with WPA, we'll need a place to store the user's certs for authentication against the access point and RADIUS server. Evolution stores user certs. Many other things do as well. Its just plain dumb to have this stuff everywhere and not manageable by an application. Dan From skvidal at phy.duke.edu Tue Apr 19 20:24:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 19 Apr 2005 16:24:37 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <1113941995.31062.5.camel@dcbw.boston.redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <1113941995.31062.5.camel@dcbw.boston.redhat.com> Message-ID: <1113942277.15629.33.camel@cutter> > +1 from me. From a desktop perspective, we need _one_ place to store > user certs and keys. For example, in the future when NetworkManager > supports 802.1x and wireless authentication with WPA, we'll need a place > to store the user's certs for authentication against the access point > and RADIUS server. Evolution stores user certs. Many other things do > as well. Its just plain dumb to have this stuff everywhere and not > manageable by an application. > Well lets be clear - user certs shouldn't be in /etc users shouldn't be able to write to /etc users' keys should be either in their home dir or on some sort of removeable media. -sv From pjones at redhat.com Tue Apr 19 21:14:40 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 19 Apr 2005 17:14:40 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <1113942277.15629.33.camel@cutter> References: <1113941222.10777.58.camel@localhost.localdomain> <1113941995.31062.5.camel@dcbw.boston.redhat.com> <1113942277.15629.33.camel@cutter> Message-ID: <1113945280.15050.15.camel@localhost.localdomain> On Tue, 2005-04-19 at 16:24 -0400, seth vidal wrote: > > +1 from me. From a desktop perspective, we need _one_ place to store > > user certs and keys. For example, in the future when NetworkManager > > supports 802.1x and wireless authentication with WPA, we'll need a place > > to store the user's certs for authentication against the access point > > and RADIUS server. Evolution stores user certs. Many other things do > > as well. Its just plain dumb to have this stuff everywhere and not > > manageable by an application. > > > > Well lets be clear - user certs shouldn't be in /etc > > users shouldn't be able to write to /etc > > users' keys should be either in their home dir or on some sort of > removeable media. Well, really isn't he talking about user-acquired certs for the machine? It's not quite the same thing as either case. -- Peter From jorton at redhat.com Tue Apr 19 22:21:29 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 19 Apr 2005 23:21:29 +0100 Subject: where 'o where to store certificates and keys In-Reply-To: <1113941222.10777.58.camel@localhost.localdomain> References: <1113941222.10777.58.camel@localhost.localdomain> Message-ID: <20050419222129.GA12387@redhat.com> On Tue, Apr 19, 2005 at 04:07:02PM -0400, John Dennis wrote: > At the moment we have an ad hoc approach to where we store ssl > certificates and other keys. The openssl package installs > into /usr/share/ssl and some packages store their keys > in /usr/share/ssl/certs/{public,private} because of the lack of anything > better and its the closest thing we have to a standard location. Other > packages (e.g. httpd) store their keys in their own directories. > > There are three major reasons to create a new uniform location, and this > is a proposal to do so: /etc/keys/{public,private} is a bit minimal, I think we really need to take enough time to address where to put CRLs, the CA bundle, and everything else that currently goes in /usr/share/ssl/* and /etc/httpd/conf/ssl.* in one shot at least, otherwise we'll spend a couple of release mucking users about by moving stuff around. /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki or /etc/ssl, unless anyone has plans to put anything other than X.509 stuff in there? joe From skvidal at phy.duke.edu Tue Apr 19 22:23:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 19 Apr 2005 18:23:36 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <20050419222129.GA12387@redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> Message-ID: <1113949416.15629.45.camel@cutter> > /etc/keys/{public,private} is a bit minimal, I think we really need to > take enough time to address where to put CRLs, the CA bundle, and > everything else that currently goes in /usr/share/ssl/* and > /etc/httpd/conf/ssl.* in one shot at least, otherwise we'll spend a > couple of release mucking users about by moving stuff around. > > /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki > or /etc/ssl, unless anyone has plans to put anything other than X.509 > stuff in there? if that's the case go with /etc/ssl over /etc/pki - if only b/c from the sysadmins I know - most know what ssl is - not everyone knows what pki is. -sv From gafton at redhat.com Tue Apr 19 22:25:09 2005 From: gafton at redhat.com (Cristian Gafton) Date: Tue, 19 Apr 2005 18:25:09 -0400 (EDT) Subject: where 'o where to store certificates and keys In-Reply-To: <20050419222129.GA12387@redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> Message-ID: On Tue, 19 Apr 2005, Joe Orton wrote: > /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki > or /etc/ssl, unless anyone has plans to put anything other than X.509 > stuff in there? I like /etc/ssl too - "keys" is both too generic and not all that intuitive Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton at redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Linux is a leprosy; and is having a deleterious effect on the U.S. IT industry because it is steadily depreciating the value of the software industry sector." -- Kenneth Brown, President, Alexis de Tocqueville Institution From jdennis at redhat.com Tue Apr 19 22:27:37 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 19 Apr 2005 18:27:37 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <42657DE8.1010402@redhat.com> References: <42657DE8.1010402@redhat.com> Message-ID: <1113949657.10777.83.camel@localhost.localdomain> On Tue, 2005-04-19 at 14:53 -0700, Bob Relyea wrote: > So the world is even *MORE* complicated that this. Yes, we're aware of this complication :-) > Only about half our packages use openssl to get their SSL > implementations. The other half uses NSS. > NSS store keys in in a keyX.db file and certs in certX.db. To make > matters worst, like openSSL apps, > NSS apps typically store their own copy of the database somewhere in the > user's profile. We're not talking about user keys and certs, rather system services specific to the host which have public and private keys and certificates, the obvious examples are network services providing SSL connections, but other examples exist. > I agree we need to solve this problem, but I think we need to take a > step back and understand how > each application uses it's keys and certs. Just saying the keys and > certs live in a particular directory > is not sufficient. > > I wish I had seen this discussion earlier. It appears to have completely > punted on applications that use NSS. I'll confess I'm not that familar with NSS, but if NSS wants to store things in a .db file, and even if multiple .db files need to live in the same directory I don't see why /etc/keys or one of its subdirs wouldn't meet that requirement (.db files are just simple files, right?) But once again, just to be clear, users are NOT going to be writing their keys/certificates in /etc/keys. If a service wants to maintain a database of per user keys/certificates in /etc/keys I don't see a problem with that because its the service (running with proper permissions) who is managing that data, not the user. -- John Dennis From jdennis at redhat.com Tue Apr 19 22:44:02 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 19 Apr 2005 18:44:02 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <20050419222129.GA12387@redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> Message-ID: <1113950642.10777.94.camel@localhost.localdomain> On Tue, 2005-04-19 at 23:21 +0100, Joe Orton wrote: > /etc/keys/{public,private} is a bit minimal, I think we really need to > take enough time to address where to put CRLs, the CA bundle, and > everything else that currently goes in /usr/share/ssl/* and > /etc/httpd/conf/ssl.* in one shot at least, otherwise we'll spend a > couple of release mucking users about by moving stuff around. Agreed! However, I wanted to make progress rather than thrash without resolution, which has tended to be the history of this topic :-) I'm afraid getting it "all correct" is a tall order and the issue of breaking apps who are used to the /usr/share/ssl location has to be taken into consideration. A gradual migration away from /usr/share/ssl might be more practical, but like I said you make a valid point. Any reason why CRL's and the CA bundle couldn't live there as well (whatever the name is)? > /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki > or /etc/ssl, unless anyone has plans to put anything other than X.509 > stuff in there? We kinda knew the name would be controversal. There was an expectation that things other than X.509 could live there too, hence the generic name, but a "rose is a rose" :-) whatever name folks are happy with. -- John Dennis From dwmw2 at infradead.org Tue Apr 19 22:50:39 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 20 Apr 2005 08:50:39 +1000 Subject: where 'o where to store certificates and keys In-Reply-To: <1113941222.10777.58.camel@localhost.localdomain> References: <1113941222.10777.58.camel@localhost.localdomain> Message-ID: <1113951040.17133.7.camel@localhost.localdomain> On Tue, 2005-04-19 at 16:07 -0400, John Dennis wrote: > I know this has been debated before, be we've got to make a decision and > move forward (in part because this is now gating some work on my > plate :-). I've had a hallway conversation with Nalin and Dan Walsh and > it was agreed this was the most palatable option at the moment (not > ideal, but a workable solution). ACK. While we're at it -- is there any way we could get the keys generated _after_ the install? We could have something in firstboot which collects all the information required for SSL certs, rather than just using 'SomeState' etc. Even if we don't take it that far, if we just generate the certs _without_ user input during the first boot sequence then we're at least likely to get a decent hostname instead of 'localhost.localdomain'. It's also been suggested that we should also assign random sequence numbers to generated certs, because people are seeing errors reported due to 'duplicate' autogenerated certs. -- dwmw2 From cra at WPI.EDU Wed Apr 20 03:02:59 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Tue, 19 Apr 2005 23:02:59 -0400 Subject: Fedora Legacy, and What's Happening to *Your* FC2 Bugs.... In-Reply-To: <4264E4B9.8080201@www.linux.org.uk> References: <20050414161815.GA15677@jadzia.bu.edu> <4264E4B9.8080201@www.linux.org.uk> Message-ID: <20050420030259.GA28636@angus.ind.WPI.EDU> On Tue, Apr 19, 2005 at 07:00:09AM -0400, Mike A. Harris wrote: > Basically, you can just ignore xgl-maint bugs and they'll take > care of themselves very soon if they haven't been already. Yeah, you just have to ignore bugs that are FIXED/RAWHIDE until FCx goes EOL/transfers to Legacy, and then you don't have to worry about that pesky 6-12 month FC maintenance period. Heck, why have FCx releases at all when you can install rawhide almost any day... From ville.skytta at iki.fi Wed Apr 20 06:19:33 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 20 Apr 2005 09:19:33 +0300 Subject: where 'o where to store certificates and keys In-Reply-To: <20050419222129.GA12387@redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> Message-ID: <1113977973.6812.126.camel@bobcat.mine.nu> On Tue, 2005-04-19 at 23:21 +0100, Joe Orton wrote: > /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki > or /etc/ssl, unless anyone has plans to put anything other than X.509 > stuff in there? +1 to /etc/pki (or /etc/security/pki). SSL stuff could be placed in a subdir there. From skvidal at phy.duke.edu Wed Apr 20 13:05:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 20 Apr 2005 09:05:39 -0400 Subject: Checking in packages for extras Message-ID: <1114002339.15629.55.camel@cutter> Hey folks, when you check in a package/changes that you're going to request to be built, please run 'make tag' in the directory you're checking in. thanks, -sv From dcbw at redhat.com Wed Apr 20 13:37:12 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 20 Apr 2005 09:37:12 -0400 (EDT) Subject: where 'o where to store certificates and keys In-Reply-To: <1113977973.6812.126.camel@bobcat.mine.nu> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <1113977973.6812.126.camel@bobcat.mine.nu> Message-ID: On Wed, 20 Apr 2005, Ville [ISO-8859-1] Skytt? wrote: > On Tue, 2005-04-19 at 23:21 +0100, Joe Orton wrote: > > > /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki > > or /etc/ssl, unless anyone has plans to put anything other than X.509 > > stuff in there? > > +1 to /etc/pki (or /etc/security/pki). SSL stuff could be placed in a > subdir there. In the case of 802.1x when using WPA of some sort (also called "Enterprise WPA") there is certainly no SSL involved. Therefore, I would also vote for /etc/pki or /etc/security/pki. Dan From alan at redhat.com Wed Apr 20 13:57:20 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Apr 2005 09:57:20 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> Message-ID: <20050420135720.GD10443@devserv.devel.redhat.com> On Tue, Apr 19, 2005 at 06:25:09PM -0400, Cristian Gafton wrote: > I like /etc/ssl too - "keys" is both too generic and not all that > intuitive Not all our keys are SSL keys (in fact the very "SSL" is obsolete). It would be /etc/tls. I'd favour /etc/keys/tls /etc/keys/sshd /etc/keys/afs /etc/keys/radius etc From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 20 14:11:28 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 20 Apr 2005 16:11:28 +0200 Subject: Checking in packages for extras In-Reply-To: <1114002339.15629.55.camel@cutter> References: <1114002339.15629.55.camel@cutter> Message-ID: <20050420161128.2628a9b4@python2> seth vidal wrote : > when you check in a package/changes that you're going to request to be > built, please run 'make tag' in the directory you're checking in. Just out of curiosity, does this mean that your build system can now get the latest tag automatically and build it? Are we one step away from automatically triggered builds based on new tags? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.35 0.81 0.73 From alan at redhat.com Wed Apr 20 14:12:37 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Apr 2005 10:12:37 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <1113977973.6812.126.camel@bobcat.mine.nu> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <1113977973.6812.126.camel@bobcat.mine.nu> Message-ID: <20050420141237.GH10443@devserv.devel.redhat.com> On Wed, Apr 20, 2005 at 09:19:33AM +0300, Ville Skytt? wrote: > On Tue, 2005-04-19 at 23:21 +0100, Joe Orton wrote: > > > /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki > > or /etc/ssl, unless anyone has plans to put anything other than X.509 > > stuff in there? > > +1 to /etc/pki (or /etc/security/pki). SSL stuff could be placed in a > subdir there. That I like. That or "certificates" From skvidal at phy.duke.edu Wed Apr 20 14:14:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 20 Apr 2005 10:14:00 -0400 Subject: Checking in packages for extras In-Reply-To: <20050420161128.2628a9b4@python2> References: <1114002339.15629.55.camel@cutter> <20050420161128.2628a9b4@python2> Message-ID: <1114006441.15629.61.camel@cutter> On Wed, 2005-04-20 at 16:11 +0200, Matthias Saou wrote: > seth vidal wrote : > > > when you check in a package/changes that you're going to request to be > > built, please run 'make tag' in the directory you're checking in. > > Just out of curiosity, does this mean that your build system can now get > the latest tag automatically and build it? Are we one step away from > automatically triggered builds based on new tags? > we're very few steps away, yes. if you noticed all the 'tobuild' updates I was making yesterday it was me testing this stuff and working bugs out. -sv From dwalsh at redhat.com Wed Apr 20 14:09:38 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 20 Apr 2005 10:09:38 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <20050420135720.GD10443@devserv.devel.redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420135720.GD10443@devserv.devel.redhat.com> Message-ID: <426662A2.7070208@redhat.com> I think we need a benevolent dictator to choose a name. Bill??? Dan -- From dwmw2 at infradead.org Wed Apr 20 14:19:01 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 21 Apr 2005 00:19:01 +1000 Subject: where 'o where to store certificates and keys In-Reply-To: <1113941222.10777.58.camel@localhost.localdomain> References: <1113941222.10777.58.camel@localhost.localdomain> Message-ID: <1114006742.5877.45.camel@localhost.localdomain> On Tue, 2005-04-19 at 16:07 -0400, John Dennis wrote: > Individual applications can make use of these directories in whatever > fashion they desire, as long as the files they install there are > certificates or keys of any form. They set their own permissions and > ownerships. Can we have a script which does this for us please? Rather than reimplementing the key generation in each %post script (or maybe init script since that would allow it to get the hostname right and happen after firstboot), it'd be useful just to invoke a helper script which does it for us. There's too much random stuff copied from specfile to specfile atm. -- dwmw2 From shahms at shahms.com Wed Apr 20 14:22:28 2005 From: shahms at shahms.com (Shahms King) Date: Wed, 20 Apr 2005 07:22:28 -0700 Subject: Checking in packages for extras In-Reply-To: <1114006441.15629.61.camel@cutter> References: <1114002339.15629.55.camel@cutter> <20050420161128.2628a9b4@python2> <1114006441.15629.61.camel@cutter> Message-ID: <426665A4.1040203@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: | On Wed, 2005-04-20 at 16:11 +0200, Matthias Saou wrote: | |>seth vidal wrote : |> |> |>> when you check in a package/changes that you're going to request to be |>>built, please run 'make tag' in the directory you're checking in. |> |>Just out of curiosity, does this mean that your build system can now get |>the latest tag automatically and build it? Are we one step away from |>automatically triggered builds based on new tags? |> | | | we're very few steps away, yes. | | if you noticed all the 'tobuild' updates I was making yesterday it was | me testing this stuff and working bugs out. | | -sv "Sweet". One question: How does one request (make tag) on two different branches? It seems bad form to increment the release in one specfile just to get a different tag and two branches cannot have the same tag. - -- 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 iD8DBQFCZmWj/qs2NkWy11sRAvFiAKCjtwO+aeylCr9SyMQeYh71VWk7DACfa6Uc YIyJlLsXeV9uGFa1DEZdil4= =6LG5 -----END PGP SIGNATURE----- From katzj at redhat.com Wed Apr 20 14:27:30 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Apr 2005 10:27:30 -0400 Subject: Checking in packages for extras In-Reply-To: <426665A4.1040203@shahms.com> References: <1114002339.15629.55.camel@cutter> <20050420161128.2628a9b4@python2> <1114006441.15629.61.camel@cutter> <426665A4.1040203@shahms.com> Message-ID: <1114007250.11399.0.camel@bree.local.net> On Wed, 2005-04-20 at 07:22 -0700, Shahms King wrote: > "Sweet". One question: How does one request (make tag) on two different > branches? It seems bad form to increment the release in one specfile > just to get a different tag and two branches cannot have the same tag. You want to have a different EVR for the packages for different branches anyway. Jeremy From alan at redhat.com Wed Apr 20 14:31:07 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Apr 2005 10:31:07 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <426662A2.7070208@redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420135720.GD10443@devserv.devel.redhat.com> <426662A2.7070208@redhat.com> Message-ID: <20050420143107.GN10443@devserv.devel.redhat.com> On Wed, Apr 20, 2005 at 10:09:38AM -0400, Daniel J Walsh wrote: > I think we need a benevolent dictator to choose a name. Bill??? /bill doesn't really work From rrelyea at redhat.com Tue Apr 19 21:53:44 2005 From: rrelyea at redhat.com (Bob Relyea) Date: Tue, 19 Apr 2005 14:53:44 -0700 Subject: where 'o where to store certificates and keys Message-ID: <42657DE8.1010402@redhat.com> > > >At the moment we have an ad hoc approach to where we store ssl >certificates and other keys. The openssl package installs >into /usr/share/ssl and some packages store their keys >in /usr/share/ssl/certs/{public,private} because of the lack of anything >better and its the closest thing we have to a standard location. Other >packages (e.g. httpd) store their keys in their own directories. > > So the world is even *MORE* complicated that this. Only about half our packages use openssl to get their SSL implementations. The other half uses NSS. NSS store keys in in a keyX.db file and certs in certX.db. To make matters worst, like openSSL apps, NSS apps typically store their own copy of the database somewhere in the user's profile. I agree we need to solve this problem, but I think we need to take a step back and understand how each application uses it's keys and certs. Just saying the keys and certs live in a particular directory is not sufficient. I wish I had seen this discussion earlier. It appears to have completely punted on applications that use NSS. >There are three major reasons to create a new uniform location, and this >is a proposal to do so: > >1) /usr/share is designed to be NFS mounted and shared. Private >certificates and keys really should not be located by default in a >directory visible to many machines on the network. /usr/share is an >insecure location. > >2) SELinux labeling and policy authorship would be much easier and more >robust if we collected certificates and keys in one place and label >those files appropriately. > >3) Certificates and keys are not a property of the openssl package, >there should be a package neutral location in the spirit of FHS to >locate all certificate and key files which can be shared by all >packages. Someplace in /etc seems ideal. > >Proposal: the filesystem rpm creates the following 3 new directories > >/etc/keys >/etc/keys/public >/etc/keys/private > > This certainly is not going to work with existing NSS apps like evolution or Firefox. They expect their key and cert databases to live in the same directory. >Individual applications can make use of these directories in whatever >fashion they desire, as long as the files they install there are >certificates or keys of any form. They set their own permissions and >ownerships. > > >I know this has been debated before, be we've got to make a decision and >move forward (in part because this is now gating some work on my >plate :-) . I've had a hallway conversation with Nalin and Dan Walsh and >it was agreed this was the most palatable option at the moment (not >ideal, but a workable solution). > > Again, I wish I were in on this discussion. It seems to have missed a major component which affects the overall design. bob >ACK's or NCK's please! > > -- John Dennis -- Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: S/MIME Cryptographic Signature URL: From rrelyea at redhat.com Tue Apr 19 22:54:07 2005 From: rrelyea at redhat.com (Bob Relyea) Date: Tue, 19 Apr 2005 15:54:07 -0700 Subject: where 'o where to store certificates and keys In-Reply-To: <1113949657.10777.83.camel@localhost.localdomain> References: <42657DE8.1010402@redhat.com> <1113949657.10777.83.camel@localhost.localdomain> Message-ID: <42658C0F.3060404@redhat.com> John Dennis wrote: >On Tue, 2005-04-19 at 14:53 -0700, Bob Relyea wrote: > > >>So the world is even *MORE* complicated that this. >> >> > >Yes, we're aware of this complication :-) > > > >>Only about half our packages use openssl to get their SSL >>implementations. The other half uses NSS. >>NSS store keys in in a keyX.db file and certs in certX.db. To make >>matters worst, like openSSL apps, >>NSS apps typically store their own copy of the database somewhere in the >>user's profile. >> >> > >We're not talking about user keys and certs, rather system services >specific to the host which have public and private keys and >certificates, the obvious examples are network services providing SSL >connections, but other examples exist. > > directory is an NSS app. Not all NSS apps are clients.... You still need to worry about it in the server space. It's a little better if this isn't around to solve the user key issue, though that needs to be clear given some of the responses I saw to the proposal. >>I agree we need to solve this problem, but I think we need to take a >>step back and understand how >>each application uses it's keys and certs. Just saying the keys and >>certs live in a particular directory >>is not sufficient. >> >>I wish I had seen this discussion earlier. It appears to have completely >>punted on applications that use NSS. >> >> > >I'll confess I'm not that familar with NSS, but if NSS wants to store >things in a .db file, and even if multiple .db files need to live in the >same directory I don't see why /etc/keys or one of its subdirs wouldn't >meet that requirement (.db files are just simple files, right?) > > If you just say the .db files live in /etc/keys, then yes. The proposal sounded like you were splitting /etc/keys into public an private partions (implying certs go into public and keys go into private). If you are saying /etc/keys is a 'free-for-all' and that keys and certs are stored somewhere under /etc/keys, then yes, NSS does not have a problem (NSS servers may need to be coerhersed, but we're assume some server corhersion anyway. Note that this still doesn't get all your system utilities to share their keys and certs (you still have to converge formats, regularize exactly where and how to find and manage keys and certs, etc.). >But once again, just to be clear, users are NOT going to be writing >their keys/certificates in /etc/keys. If a service wants to maintain a >database of per user keys/certificates in /etc/keys I don't see a >problem with that because its the service (running with proper >permissions) who is managing that data, not the user. > > NSS isn't just fore users anymore;). Actually, like openSSL, NSS has always been used in both clients and servers. There are several new servers coming down the pike which are NSS based. Leaving the users out of the picture does simplify what you are trying to do, but you still haven't ditched NSS as a consideration yet. bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: S/MIME Cryptographic Signature URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Apr 20 14:46:14 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 20 Apr 2005 16:46:14 +0200 Subject: Checking in packages for extras In-Reply-To: <1114007250.11399.0.camel@bree.local.net> References: <1114002339.15629.55.camel@cutter> <20050420161128.2628a9b4@python2> <1114006441.15629.61.camel@cutter> <426665A4.1040203@shahms.com> <1114007250.11399.0.camel@bree.local.net> Message-ID: <20050420164614.0ea8b1a7@python2> Jeremy Katz wrote : > On Wed, 2005-04-20 at 07:22 -0700, Shahms King wrote: > > "Sweet". One question: How does one request (make tag) on two different > > branches? It seems bad form to increment the release in one specfile > > just to get a different tag and two branches cannot have the same tag. > > You want to have a different EVR for the packages for different branches > anyway. Yup, and always make sure that the EVR of the latest built packages are ordered properly across all supported distributions (i.e. that the release tag of the FC3 build is lower than the one of the FC4 build). Thanks for the answer, seth. I saw your tests, and that's why I was asking ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 3.57 2.19 1.29 From laroche at redhat.com Wed Apr 20 16:02:07 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 20 Apr 2005 18:02:07 +0200 Subject: where 'o where to store certificates and keys In-Reply-To: <20050420143107.GN10443@devserv.devel.redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420135720.GD10443@devserv.devel.redhat.com> <426662A2.7070208@redhat.com> <20050420143107.GN10443@devserv.devel.redhat.com> Message-ID: <20050420160207.GB11180@dudweiler.stuttgart.redhat.com> On Wed, Apr 20, 2005 at 10:31:07AM -0400, Alan Cox wrote: > On Wed, Apr 20, 2005 at 10:09:38AM -0400, Daniel J Walsh wrote: > > I think we need a benevolent dictator to choose a name. Bill??? > > /bill doesn't really work Nonono, I think our Bill works way better than other Bills. Haven't you noticed the difference? ;-) greetings, Florian La Roche From notting at redhat.com Wed Apr 20 16:42:20 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Apr 2005 12:42:20 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <20050419222129.GA12387@redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> Message-ID: <20050420164220.GA28313@nostromo.devel.redhat.com> Joe Orton (jorton at redhat.com) said: > /etc/keys is not the obvious choice of name to me - I'd prefer /etc/pki > or /etc/ssl, unless anyone has plans to put anything other than X.509 > stuff in there? Well, given: - this will contain more than just SSL, TLS, SSH(?), etc. keys and certs - the end user who thinks "PKI? What's that?" shouldn't be looking at the directory - the sysadmin who thinks "PKI? What's that?" can afford some education. :) I'd think /etc/pki is more practical. Bill From davej at redhat.com Wed Apr 20 17:03:04 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Apr 2005 13:03:04 -0400 Subject: Checking in packages for extras In-Reply-To: <1114002339.15629.55.camel@cutter> References: <1114002339.15629.55.camel@cutter> Message-ID: <20050420170303.GF2476@redhat.com> On Wed, Apr 20, 2005 at 09:05:39AM -0400, seth vidal wrote: > Hey folks, > when you check in a package/changes that you're going to request to be > built, please run 'make tag' in the directory you're checking in. > > thanks, > -sv btw, are the build logs for extras packages kept anywhere public ? Dave From skvidal at phy.duke.edu Wed Apr 20 18:02:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 20 Apr 2005 14:02:42 -0400 Subject: Checking in packages for extras In-Reply-To: <20050420170303.GF2476@redhat.com> References: <1114002339.15629.55.camel@cutter> <20050420170303.GF2476@redhat.com> Message-ID: <1114020162.23497.0.camel@cutter> On Wed, 2005-04-20 at 13:03 -0400, Dave Jones wrote: > On Wed, Apr 20, 2005 at 09:05:39AM -0400, seth vidal wrote: > > Hey folks, > > when you check in a package/changes that you're going to request to be > > built, please run 'make tag' in the directory you're checking in. > > > > thanks, > > -sv > > btw, are the build logs for extras packages kept anywhere public ? > They've been at: http://fedoraproject.org/extras/development/build-logs/ since the beginning of building extras for devel. -sv From jdennis at redhat.com Wed Apr 20 19:08:56 2005 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Apr 2005 15:08:56 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <20050420164220.GA28313@nostromo.devel.redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420164220.GA28313@nostromo.devel.redhat.com> Message-ID: <1114024136.10805.14.camel@localhost.localdomain> On Wed, 2005-04-20 at 12:42 -0400, Bill Nottingham wrote: > I'd think /etc/pki is more practical. Done, the name is chosen and the directory /etc/pki has been added making its appearance in filesystem-2.3.2-1. The recommendation is for each package to create a subdirectory under /etc/pki with its own name. This is the most general solution, its mimics recommendations in much of FHS, packages get their own area and can do whatever they please without impacting anybody else, and its makes it easier to enforce security via permissions, ownership, and SELinux policy. -- John Dennis From cra at WPI.EDU Wed Apr 20 19:18:53 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Wed, 20 Apr 2005 15:18:53 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <1114024136.10805.14.camel@localhost.localdomain> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420164220.GA28313@nostromo.devel.redhat.com> <1114024136.10805.14.camel@localhost.localdomain> Message-ID: <20050420191853.GG4369@angus.ind.WPI.EDU> On Wed, Apr 20, 2005 at 03:08:56PM -0400, John Dennis wrote: > On Wed, 2005-04-20 at 12:42 -0400, Bill Nottingham wrote: > > I'd think /etc/pki is more practical. > > Done, the name is chosen and the directory /etc/pki has been added > making its appearance in filesystem-2.3.2-1. What about symmetric keys? Those don't fall under Public Key Infrastructure. From alan at redhat.com Wed Apr 20 22:34:51 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 20 Apr 2005 18:34:51 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <1114024136.10805.14.camel@localhost.localdomain> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420164220.GA28313@nostromo.devel.redhat.com> <1114024136.10805.14.camel@localhost.localdomain> Message-ID: <20050420223451.GE6644@devserv.devel.redhat.com> On Wed, Apr 20, 2005 at 03:08:56PM -0400, John Dennis wrote: > On Wed, 2005-04-20 at 12:42 -0400, Bill Nottingham wrote: > > I'd think /etc/pki is more practical. > > Done, the name is chosen and the directory /etc/pki has been added > making its appearance in filesystem-2.3.2-1. Cool - is it worth submitting that proposal to the FSSTND people ? Its a multi-vendor issue and "where to put keys" will become an app issue more and more over time. From ivazquez at ivazquez.net Thu Apr 21 01:08:29 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 20 Apr 2005 21:08:29 -0400 Subject: Checking in packages for extras In-Reply-To: <1114007250.11399.0.camel@bree.local.net> References: <1114002339.15629.55.camel@cutter> <20050420161128.2628a9b4@python2> <1114006441.15629.61.camel@cutter> <426665A4.1040203@shahms.com> <1114007250.11399.0.camel@bree.local.net> Message-ID: <1114045709.13656.102.camel@ignacio.ignacio.lan> On Wed, 2005-04-20 at 10:27 -0400, Jeremy Katz wrote: > On Wed, 2005-04-20 at 07:22 -0700, Shahms King wrote: > > "Sweet". One question: How does one request (make tag) on two different > > branches? It seems bad form to increment the release in one specfile > > just to get a different tag and two branches cannot have the same tag. > > You want to have a different EVR for the packages for different branches > anyway. Wouldn't that be only if the requires are different? -- 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 Apr 21 02:04:43 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Apr 2005 22:04:43 -0400 Subject: Checking in packages for extras In-Reply-To: <1114045709.13656.102.camel@ignacio.ignacio.lan> References: <1114002339.15629.55.camel@cutter> <20050420161128.2628a9b4@python2> <1114006441.15629.61.camel@cutter> <426665A4.1040203@shahms.com> <1114007250.11399.0.camel@bree.local.net> <1114045709.13656.102.camel@ignacio.ignacio.lan> Message-ID: <1114049083.11399.29.camel@bree.local.net> On Wed, 2005-04-20 at 21:08 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-04-20 at 10:27 -0400, Jeremy Katz wrote: > > On Wed, 2005-04-20 at 07:22 -0700, Shahms King wrote: > > > "Sweet". One question: How does one request (make tag) on two different > > > branches? It seems bad form to increment the release in one specfile > > > just to get a different tag and two branches cannot have the same tag. > > > > You want to have a different EVR for the packages for different branches > > anyway. > > Wouldn't that be only if the requires are different? No, if the packages are different (and are going to be built in different build roots, etc), then you want to have them distinguishable by something that's in the standard packages headers. Which essentially gives you EVR to differentiate on. And realistically, just release (since changing the version or the epoch for a different distribution is just crack ;) Jeremy From jdennis at redhat.com Thu Apr 21 02:28:08 2005 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Apr 2005 22:28:08 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <20050420223451.GE6644@devserv.devel.redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420164220.GA28313@nostromo.devel.redhat.com> <1114024136.10805.14.camel@localhost.localdomain> <20050420223451.GE6644@devserv.devel.redhat.com> Message-ID: <1114050488.15655.2.camel@localhost.localdomain> On Wed, 2005-04-20 at 18:34 -0400, Alan Cox wrote: > On Wed, Apr 20, 2005 at 03:08:56PM -0400, John Dennis wrote: > > On Wed, 2005-04-20 at 12:42 -0400, Bill Nottingham wrote: > > > I'd think /etc/pki is more practical. > > > > Done, the name is chosen and the directory /etc/pki has been added > > making its appearance in filesystem-2.3.2-1. > > Cool - is it worth submitting that proposal to the FSSTND people ? Its > a multi-vendor issue and "where to put keys" will become an app issue more > and more over time. Yes, I agree and I'll do that. -- John Dennis From oliver at linux-kernel.at Thu Apr 21 07:29:31 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 21 Apr 2005 09:29:31 +0200 Subject: where 'o where to store certificates and keys In-Reply-To: <20050420223451.GE6644@devserv.devel.redhat.com> Message-ID: <200504210728.j3L7SkFH024793@mail.linux-kernel.at> Alan Cox wrote: > On Wed, Apr 20, 2005 at 03:08:56PM -0400, John Dennis wrote: > > On Wed, 2005-04-20 at 12:42 -0400, Bill Nottingham wrote: > > > I'd think /etc/pki is more practical. > > > > Done, the name is chosen and the directory /etc/pki has been added > > making its appearance in filesystem-2.3.2-1. What's about the local user keys. Is ~/.pki choosen? > Cool - is it worth submitting that proposal to the FSSTND > people ? Its a multi-vendor issue and "where to put keys" > will become an app issue more and more over time. /me thinks it should be submitted as proposal. I don't need to explain the 'why', because you allready did, Alan. :-) Best, Oliver From oliver at linux-kernel.at Thu Apr 21 08:14:24 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 21 Apr 2005 10:14:24 +0200 Subject: Checking in packages for extras In-Reply-To: <1114002339.15629.55.camel@cutter> Message-ID: <200504210813.j3L8DeJD002101@mail.linux-kernel.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Seth! > Hey folks, > when you check in a package/changes that you're going to > request to be built, please run 'make tag' in the directory > you're checking in. The easiest way to do that is to write the build: line in Makefile.common as "build: tag", so it will tag it automatically. :-) That's what I did in my buildenv... Best, Oliver -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQmdg38VjeRnvJSlDEQJNCwCdEUIDSlhgcvq6HFeN8e7gU0n67j8AoPvv Ev8daba9lUmP6huoe9XIP/VR =uFHk -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Thu Apr 21 08:36:02 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 04:36:02 -0400 Subject: Checking in packages for extras In-Reply-To: <200504210813.j3L8DeJD002101@mail.linux-kernel.at> References: <200504210813.j3L8DeJD002101@mail.linux-kernel.at> Message-ID: <1114072562.13656.120.camel@ignacio.ignacio.lan> On Thu, 2005-04-21 at 10:14 +0200, Oliver Falk wrote: > > Hey folks, > > when you check in a package/changes that you're going to > > request to be built, please run 'make tag' in the directory > > you're checking in. > > The easiest way to do that is to write the build: line in Makefile.common as > "build: tag", so it will tag it automatically. :-) > > That's what I did in my buildenv... That assumes that you want it rebuilt on every check-in, which may or may not be true. -- 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 oliver at linux-kernel.at Thu Apr 21 08:48:32 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 21 Apr 2005 10:48:32 +0200 Subject: Checking in packages for extras In-Reply-To: <1114072562.13656.120.camel@ignacio.ignacio.lan> Message-ID: <200504210847.j3L8lmg8008917@mail.linux-kernel.at> > On Thu, 2005-04-21 at 10:14 +0200, Oliver Falk wrote: > > > Hey folks, > > > when you check in a package/changes that you're going to > > > request to > > > be built, please run 'make tag' in the directory you're > > > checking in. > > > > The easiest way to do that is to write the build: line in > > Makefile.common as > > "build: tag", so it will tag it automatically. :-) > > > > That's what I did in my buildenv... > > That assumes that you want it rebuilt on every check-in, > which may or may not be true. No, why? If I need to tag it on every 'make build', the 'tag' target can be a prerequisit, I think. So running make build would first run the tag target and afterwards proceed with the 'build' target... Best, Oliver From ivazquez at ivazquez.net Thu Apr 21 09:07:40 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 21 Apr 2005 05:07:40 -0400 Subject: Checking in packages for extras In-Reply-To: <200504210847.j3L8lmg8008917@mail.linux-kernel.at> References: <200504210847.j3L8lmg8008917@mail.linux-kernel.at> Message-ID: <1114074460.13656.123.camel@ignacio.ignacio.lan> On Thu, 2005-04-21 at 10:48 +0200, Oliver Falk wrote: > > On Thu, 2005-04-21 at 10:14 +0200, Oliver Falk wrote: > > > > Hey folks, > > > > when you check in a package/changes that you're going to > > > > request to > > > > be built, please run 'make tag' in the directory you're > > > > checking in. > > > > > > The easiest way to do that is to write the build: line in > > > Makefile.common as > > > "build: tag", so it will tag it automatically. :-) > > > > > > That's what I did in my buildenv... > > > > That assumes that you want it rebuilt on every check-in, > > which may or may not be true. > > No, why? If I need to tag it on every 'make build', the 'tag' target can be > a prerequisit, I think. So running make build would first run the tag target > and afterwards proceed with the 'build' target... Ah, you're right, I was thinking about something else. Never mind. -- 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 oliver at linux-kernel.at Thu Apr 21 09:28:42 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 21 Apr 2005 11:28:42 +0200 Subject: Checking in packages for extras In-Reply-To: <1114074460.13656.123.camel@ignacio.ignacio.lan> Message-ID: <200504210927.j3L9RvCu017510@mail.linux-kernel.at> > On Thu, 2005-04-21 at 10:48 +0200, Oliver Falk wrote: > > > On Thu, 2005-04-21 at 10:14 +0200, Oliver Falk wrote: > > > > > Hey folks, > > > > > when you check in a package/changes that you're going > > > > > to request > > > > > to be built, please run 'make tag' in the directory you're > > > > > checking in. > > > > > > > > The easiest way to do that is to write the build: line in > > > > Makefile.common as > > > > "build: tag", so it will tag it automatically. :-) > > > > > > > > That's what I did in my buildenv... > > > > > > That assumes that you want it rebuilt on every check-in, > > > which may > > > or may not be true. > > > > No, why? If I need to tag it on every 'make build', the > > 'tag' target > > can be a prerequisit, I think. So running make build would > > first run > > the tag target and afterwards proceed with the 'build' target... > > Ah, you're right, I was thinking about something else. Never mind. No problem, I allready guessed so :-) Best, Oliver From skvidal at phy.duke.edu Thu Apr 21 17:41:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 21 Apr 2005 13:41:27 -0400 Subject: seahorse takeover Message-ID: <1114105287.23497.42.camel@cutter> Hi all, I talked with Phillip and he okay'd my taking over seahorse in fedora-extras. -sv From tmraz at redhat.com Thu Apr 21 22:29:37 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 22 Apr 2005 00:29:37 +0200 Subject: /usr/share/ssl moved Message-ID: <1114122577.5886.43.camel@perun.redhat.usu> This is a result of the change discussed on this list. In the openssl-0.9.7f-4 the /usr/share/ssl contents is moved to /etc/pki/tls and /etc/pki/CA. The remaining files in the /usr/share/ssl directory are owned by dovecot package which should be changed appropriately. -- Tomas Mraz From nphilipp at redhat.com Fri Apr 22 07:55:03 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 22 Apr 2005 09:55:03 +0200 Subject: Checking in packages for extras In-Reply-To: <200504210813.j3L8DeJD002101@mail.linux-kernel.at> References: <200504210813.j3L8DeJD002101@mail.linux-kernel.at> Message-ID: <1114156503.6017.14.camel@wombat.tiptoe.de> On Thu, 2005-04-21 at 10:14 +0200, Oliver Falk wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Seth! > > > Hey folks, > > when you check in a package/changes that you're going to > > request to be built, please run 'make tag' in the directory > > you're checking in. > > The easiest way to do that is to write the build: line in Makefile.common as > "build: tag", so it will tag it automatically. :-) This will fail if it is tagged already (many of us Red Hatters will run make tag on one machine and make build on another courtesy of our internal build system). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From oliver at linux-kernel.at Fri Apr 22 08:36:46 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 22 Apr 2005 10:36:46 +0200 Subject: Checking in packages for extras In-Reply-To: <1114156503.6017.14.camel@wombat.tiptoe.de> Message-ID: <200504220836.j3M8a1xa000580@mail.linux-kernel.at> > > > Hey folks, > > > when you check in a package/changes that you're going to > > > request to > > > be built, please run 'make tag' in the directory you're > > > checking in. > > > > The easiest way to do that is to write the build: line in > > Makefile.common as > > "build: tag", so it will tag it automatically. :-) > > This will fail if it is tagged already (many of us Red > Hatters will run make tag on one machine and make build on > another courtesy of our internal build system). Yes, I encountered this problem allready, but that's the reason, why I 'move' the cvs tag. So my cvs tag line reads as: cvs tag -F $(TAG_OPTS) -c $(TAG) (As you can see I added -F). That works fine here. I'm sure, that you, Red Hatters, do work this way and I also work this way very often, but for the most people out there - I guess - they run tag and build on the same machine!? The reason why I always tag it before building, is that I cannot forget it then. :-) Best, Oliver PS: It was just any idea and it works fine at my boxes... From nphilipp at redhat.com Fri Apr 22 09:40:32 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 22 Apr 2005 11:40:32 +0200 Subject: Checking in packages for extras In-Reply-To: <200504220836.j3M8a1xa000580@mail.linux-kernel.at> References: <200504220836.j3M8a1xa000580@mail.linux-kernel.at> Message-ID: <1114162832.8814.2.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-04-22 at 10:36 +0200, Oliver Falk wrote: > > > > Hey folks, > > > > when you check in a package/changes that you're going to > > > > request to > > > > be built, please run 'make tag' in the directory you're > > > > checking in. > > > > > > The easiest way to do that is to write the build: line in > > > Makefile.common as > > > "build: tag", so it will tag it automatically. :-) > > > > This will fail if it is tagged already (many of us Red > > Hatters will run make tag on one machine and make build on > > another courtesy of our internal build system). > > Yes, I encountered this problem allready, but that's the reason, why I > 'move' the cvs tag. So my cvs tag line reads as: > > cvs tag -F $(TAG_OPTS) -c $(TAG) > > (As you can see I added -F). I see, but this is not what we want, trust me on that one ;-). Force-tagging should only be done if really necessary, not per default. > That works fine here. I'm sure, that you, Red Hatters, do work this way and > I also work this way very often, but for the most people out there - I guess > - they run tag and build on the same machine!? > > The reason why I always tag it before building, is that I cannot forget it > then. :-) Well our build system checks for the presence of the tag before building, maybe someone can patch Seth accordingly ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From bugs.michael at gmx.net Fri Apr 22 12:02:09 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Apr 2005 14:02:09 +0200 Subject: Fedora Extras: missing bugzilla components Message-ID: <20050422140209.10e07ee7.bugs.michael@gmx.net> 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 aiksaurus cdlabelgen cln cvsup dkms enchant enemies-of-carlotta exim-doc exim fftw3 flumotion gcl gnet2 gnome-applet-netmon hula kile-i18n lapack milter-greylist nabi octave-forge ogmtools ots plt-scheme python-cherrypy python-cherrytemplate quilt tdl tetex-bytefield util-vserver xmms-arts xmms-skins xmms yap From mharris at www.linux.org.uk Fri Apr 22 12:27:41 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Fri, 22 Apr 2005 08:27:41 -0400 Subject: Checking in packages for extras In-Reply-To: <200504220836.j3M8a1xa000580@mail.linux-kernel.at> References: <200504220836.j3M8a1xa000580@mail.linux-kernel.at> Message-ID: <4268EDBD.20600@www.linux.org.uk> Oliver Falk wrote: > Yes, I encountered this problem allready, but that's the reason, why I > 'move' the cvs tag. So my cvs tag line reads as: > > cvs tag -F $(TAG_OPTS) -c $(TAG) > > (As you can see I added -F). > > That works fine here. I'm sure, that you, Red Hatters, do work this way and > I also work this way very often, but for the most people out there - I guess > - they run tag and build on the same machine!? force-tag is something that should never ever be used by default. Just as it is easy to forget to tag something, it is easy to forget that you already tagged something, and then blow it away by accident. If -F was the default, and the last build released to the community was 6.8.2-22, and I check in 10 patches, various spec file updates and do "make build", if it did '-F' and I forget to bump the spec file release, I just moved the -22 tag from where it was, to the current state of the tree, effectively blowing away the actual released -22 release from being able to be checked out of CVS. > The reason why I always tag it before building, is that I cannot forget it > then. :-) Our buildsystem only builds things that are tagged, so we don't have that problem. If we forget to tag, it will present some horrible error messages to us to make sure we remember. ;o) From bugs.michael at gmx.net Fri Apr 22 12:48:41 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 22 Apr 2005 14:48:41 +0200 Subject: Fedora Extras: packages with EVR upgrade problems Message-ID: <20050422144841.3f2334cb.bugs.michael@gmx.net> CVS based EVR comparison. EVR of packages built for Fedora Extras Development should be higher than packages for Fedora Extras FC3: R-gnomeGUI 0:2.1.0-1.fc3 in FC-3 branch is newer than devel gpredict 0:0.5.0-5 in FC-3 branch is newer than devel udunits 0:1.12.4-5.fc3 in FC-3 branch is newer than devel apg 0:2.3.0b-1 in FC-3 branch is equal to devel audacity 0:1.2.3-3 in FC-3 branch is equal to devel feh 0:1.3.0-2 in FC-3 branch is equal to devel gcl 0:2.6.6-2 in FC-3 branch is equal to devel gnome-theme-clearlooks 0:0.5-3 in FC-3 branch is equal to devel graveman 0:0.3.10-2 in FC-3 branch is equal to devel leafpad 0:0.7.9-6 in FC-3 branch is equal to devel libosip 0:0.9.7-6 in FC-3 branch is equal to devel lock-keys-applet 0:1.0-8 in FC-3 branch is equal to devel notecase 0:0.8.2-6 in FC-3 branch is equal to devel perl-Config-Record 0:1.1.0-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-cherrypy 0:2.0.0-0.2.b in FC-3 branch is equal to devel python-cherrytemplate 0:1.0.0-1 in FC-3 branch is equal to devel python-durus 0:1.5-1 in FC-3 branch is equal to devel sqlite 0:3.1.2-0.3 in FC-3 branch is equal to devel tla 0:1.3.1-4.fix.1 in FC-3 branch is equal to devel From jpo at di.uminho.pt Fri Apr 22 12:57:39 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Fri, 22 Apr 2005 13:57:39 +0100 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050422144841.3f2334cb.bugs.michael@gmx.net> References: <20050422144841.3f2334cb.bugs.michael@gmx.net> Message-ID: <4268F4C3.4020008@di.uminho.pt> Michael Schwendt wrote: > 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 These BioPerl packages are still under review (not approved). 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 * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From oliver at linux-kernel.at Fri Apr 22 12:59:56 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 22 Apr 2005 14:59:56 +0200 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050422144841.3f2334cb.bugs.michael@gmx.net> Message-ID: <200504221259.j3MCxBAs018280@mail.linux-kernel.at> [ ... ] > CVS based EVR comparison. EVR of packages built for Fedora > Extras Development should be higher than packages for Fedora > Extras FC3: [ ... ] > apg 0:2.3.0b-1 in FC-3 branch is equal to devel audacity Did apg, adding _FC4 to the release tag. [ ... ] > perl-Config-Record 0:1.1.0-1 in FC-3 branch is equal to devel Did this as well. Sorry, forgot, that this is not mine at Fedora (had my own at my site...). [ ... ] Best, Oliver From oliver at linux-kernel.at Fri Apr 22 13:04:40 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 22 Apr 2005 15:04:40 +0200 Subject: Checking in packages for extras In-Reply-To: <1114162832.8814.2.camel@gibraltar.stuttgart.redhat.com> Message-ID: <200504221303.j3MD3thN019474@mail.linux-kernel.at> > On Fri, 2005-04-22 at 10:36 +0200, Oliver Falk wrote: > > > > > Hey folks, > > > > > when you check in a package/changes that you're going to > > > > > request to be built, please run 'make tag' in the directory > > > > > you're checking in. > > > > > > > > The easiest way to do that is to write the build: line in > > > > Makefile.common as > > > > "build: tag", so it will tag it automatically. :-) > > > > > > This will fail if it is tagged already (many of us Red > > > Hatters will > > > run make tag on one machine and make build on another courtesy of > > > our internal build system). > > > > Yes, I encountered this problem allready, but that's the > > reason, why I > > 'move' the cvs tag. So my cvs tag line reads as: > > > > cvs tag -F $(TAG_OPTS) -c $(TAG) > > > > (As you can see I added -F). > > I see, but this is not what we want, trust me on that one ;-). > Force-tagging should only be done if really necessary, not > per default. I trust you! :-) > > That works fine here. I'm sure, that you, Red Hatters, do work this > > way and I also work this way very often, but for the most > > people out > > there - I guess > > - they run tag and build on the same machine!? > > > > The reason why I always tag it before building, is that I cannot > > forget it then. :-) > > Well our build system checks for the presence of the tag > before building, maybe someone can patch Seth accordingly ;-). OK, OK. You are all correct. Forcing it should be done with thinking what doing, not automatically. At my site, I don't mind... :-) Best, Oliver From skvidal at phy.duke.edu Fri Apr 22 13:19:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 22 Apr 2005 09:19:50 -0400 Subject: Checking in packages for extras In-Reply-To: <1114162832.8814.2.camel@gibraltar.stuttgart.redhat.com> References: <200504220836.j3M8a1xa000580@mail.linux-kernel.at> <1114162832.8814.2.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1114175990.3489.0.camel@cutter> > Well our build system checks for the presence of the tag before > building, maybe someone can patch Seth accordingly ;-). The build system automation code requires tagged source. Otherwise it won't know where to build from. -sv From jwboyer at jdub.homelinux.org Fri Apr 22 13:37:33 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 22 Apr 2005 08:37:33 -0500 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050422140209.10e07ee7.bugs.michael@gmx.net> References: <20050422140209.10e07ee7.bugs.michael@gmx.net> Message-ID: <20050422133733.GA26440@yoda.jdub.homelinux.org> On Fri, Apr 22, 2005 at 02:02:09PM +0200, Michael Schwendt wrote: > 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 > > quilt I added a request for quilt this morning. thx, josh From tcallawa at redhat.com Fri Apr 22 14:30:02 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 22 Apr 2005 09:30:02 -0500 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050422144841.3f2334cb.bugs.michael@gmx.net> References: <20050422144841.3f2334cb.bugs.michael@gmx.net> Message-ID: <1114180203.3297.89.camel@localhost.localdomain> On Fri, 2005-04-22 at 14:48 +0200, Michael Schwendt wrote: > R-gnomeGUI 0:2.1.0-1.fc3 in FC-3 branch is newer than devel > udunits 0:1.12.4-5.fc3 in FC-3 branch is newer than devel Fixed in CVS. ~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 tmraz at redhat.com Fri Apr 22 15:07:20 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 22 Apr 2005 17:07:20 +0200 Subject: /usr/share/ssl moved In-Reply-To: <1114122577.5886.43.camel@perun.redhat.usu> References: <1114122577.5886.43.camel@perun.redhat.usu> Message-ID: <1114182441.6215.19.camel@perun.redhat.usu> On Fri, 2005-04-22 at 00:29 +0200, Tomas Mraz wrote: > This is a result of the change discussed on this list. > > In the openssl-0.9.7f-4 the /usr/share/ssl contents is moved to > /etc/pki/tls and /etc/pki/CA. > > The remaining files in the /usr/share/ssl directory are owned by dovecot > package which should be changed appropriately. And the symlink in the httpd package in /etc/httpd/conf/Makefile should point to /etc/pki/tls/certs/Makefile. -- Tomas Mraz From jorton at redhat.com Fri Apr 22 15:15:47 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 22 Apr 2005 16:15:47 +0100 Subject: /usr/share/ssl moved In-Reply-To: <1114182441.6215.19.camel@perun.redhat.usu> References: <1114122577.5886.43.camel@perun.redhat.usu> <1114182441.6215.19.camel@perun.redhat.usu> Message-ID: <20050422151547.GB7983@redhat.com> On Fri, Apr 22, 2005 at 05:07:20PM +0200, Tomas Mraz wrote: > On Fri, 2005-04-22 at 00:29 +0200, Tomas Mraz wrote: > > This is a result of the change discussed on this list. > > > > In the openssl-0.9.7f-4 the /usr/share/ssl contents is moved to > > /etc/pki/tls and /etc/pki/CA. > > > > The remaining files in the /usr/share/ssl directory are owned by dovecot > > package which should be changed appropriately. > > And the symlink in the httpd package in /etc/httpd/conf/Makefile should > point to /etc/pki/tls/certs/Makefile. I'll take care of this, thanks. joe From shahms at shahms.com Fri Apr 22 15:49:55 2005 From: shahms at shahms.com (Shahms King) Date: Fri, 22 Apr 2005 08:49:55 -0700 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050422144841.3f2334cb.bugs.michael@gmx.net> References: <20050422144841.3f2334cb.bugs.michael@gmx.net> Message-ID: <42691D23.8090305@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | python-durus 0:1.5-1 in FC-3 branch is equal to devel | tla 0:1.3.1-4.fix.1 in FC-3 branch is equal to devel Fixed in CVS. - -- 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 iD8DBQFCaR0i/qs2NkWy11sRAsZlAJwPYxVpHHduP1gmDZ0Ges/fUW/9VwCgzNQy WhlmmQqP2nm6/MY3/hcf/G4= =9EGF -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Fri Apr 22 16:15:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 22 Apr 2005 12:15:35 -0400 Subject: make tag request Message-ID: <1114186536.3489.15.camel@cutter> Hey folks, Everyone who has a build request on the fc3 or fc4 wiki pages PLEASE run make tag on your package(s). thanks, -sv From ivazquez at ivazquez.net Fri Apr 22 20:00:42 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 22 Apr 2005 16:00:42 -0400 Subject: Fedora Extras: packages with EVR upgrade problems In-Reply-To: <20050422144841.3f2334cb.bugs.michael@gmx.net> References: <20050422144841.3f2334cb.bugs.michael@gmx.net> Message-ID: <1114200042.7784.10.camel@ignacio.ignacio.lan> On Fri, 2005-04-22 at 14:48 +0200, Michael Schwendt wrote: > CVS based EVR comparison. EVR of packages built for Fedora Extras Development should be higher than packages for Fedora Extras FC3: > gpredict 0:0.5.0-5 in FC-3 branch is newer than devel And I'm sure that once gnome-vfs is in Extras this will matter. For now I'm tempted to just prune the devel branch. > gnome-theme-clearlooks 0:0.5-3 in FC-3 branch is equal to devel Mmmm.... prunes.... > leafpad 0:0.7.9-6 in FC-3 branch is equal to devel > libosip 0:0.9.7-6 in FC-3 branch is equal to devel > lock-keys-applet 0:1.0-8 in FC-3 branch is equal to devel > notecase 0:0.8.2-6 in FC-3 branch is equal to devel Fixed. > sqlite 0:3.1.2-0.3 in FC-3 branch is equal to devel I'm going to hold out on this until someone approves sqlite2. -- 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 jdennis at redhat.com Fri Apr 22 21:05:02 2005 From: jdennis at redhat.com (John Dennis) Date: Fri, 22 Apr 2005 17:05:02 -0400 Subject: /usr/share/ssl moved In-Reply-To: <1114122577.5886.43.camel@perun.redhat.usu> References: <1114122577.5886.43.camel@perun.redhat.usu> Message-ID: <1114203902.3911.94.camel@finch.boston.redhat.com> On Fri, 2005-04-22 at 00:29 +0200, Tomas Mraz wrote: > This is a result of the change discussed on this list. > > In the openssl-0.9.7f-4 the /usr/share/ssl contents is moved to > /etc/pki/tls and /etc/pki/CA. > > The remaining files in the /usr/share/ssl directory are owned by dovecot > package which should be changed appropriately. Done, package version is dovecot-0.99.14-4.fc4 -- John Dennis From bugs.michael at gmx.net Sat Apr 23 06:43:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 23 Apr 2005 08:43:34 +0200 Subject: sqlite (was: Re: Fedora Extras: packages with EVR upgrade problems) In-Reply-To: <1114200042.7784.10.camel@ignacio.ignacio.lan> References: <20050422144841.3f2334cb.bugs.michael@gmx.net> <1114200042.7784.10.camel@ignacio.ignacio.lan> Message-ID: <20050423084334.0a211e4c.bugs.michael@gmx.net> On Fri, 22 Apr 2005 16:00:42 -0400, Ignacio Vazquez-Abrams wrote: > > sqlite 0:3.1.2-0.3 in FC-3 branch is equal to devel > > I'm going to hold out on this until someone approves sqlite2. Can you post the package location on fedora-extras-list once more, please? I already work with coloured threads in Sylpheed for various mailing lists. But fedora-extras-list is really bad for reviewing and tracking package changes. As new messages keep flowing in, older threads get buried. Btw, the 3.1.2-0.3 version imported into FC-3 branch is not tagged, because the same tag is already on the devel version. So, when checking out sqlite-3_1_2-0_3, you get the devel tree. Caution. From ivazquez at ivazquez.net Sat Apr 23 07:24:24 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 23 Apr 2005 03:24:24 -0400 Subject: sqlite (was: Re: Fedora Extras: packages with EVR upgrade problems) In-Reply-To: <20050423084334.0a211e4c.bugs.michael@gmx.net> References: <20050422144841.3f2334cb.bugs.michael@gmx.net> <1114200042.7784.10.camel@ignacio.ignacio.lan> <20050423084334.0a211e4c.bugs.michael@gmx.net> Message-ID: <1114241064.7784.14.camel@ignacio.ignacio.lan> On Sat, 2005-04-23 at 08:43 +0200, Michael Schwendt wrote: > On Fri, 22 Apr 2005 16:00:42 -0400, Ignacio Vazquez-Abrams wrote: > > > > sqlite 0:3.1.2-0.3 in FC-3 branch is equal to devel > > > > I'm going to hold out on this until someone approves sqlite2. > > Can you post the package location on fedora-extras-list once more, > please? I already work with coloured threads in Sylpheed for various > mailing lists. But fedora-extras-list is really bad for reviewing and > tracking package changes. As new messages keep flowing in, older > threads get buried. I hear you on that one, trust me. > Btw, the 3.1.2-0.3 version imported into FC-3 branch is not tagged, > because the same tag is already on the devel version. So, when > checking out sqlite-3_1_2-0_3, you get the devel tree. Caution. Fixed. I couldn't delete the old tag so I bumped the FC3 release. -- 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 ville.skytta at iki.fi Sat Apr 23 19:31:12 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 23 Apr 2005 22:31:12 +0300 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <20050422140209.10e07ee7.bugs.michael@gmx.net> References: <20050422140209.10e07ee7.bugs.michael@gmx.net> Message-ID: <1114284672.23930.12.camel@bobcat.mine.nu> On Fri, 2005-04-22 at 14:02 +0200, Michael Schwendt wrote: > 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 > > ogmtools Not needed, it's on its way out due to legal concerns. http://fedoraproject.org/wiki/Extras_2fCVSSyncNeeded From tcallawa at redhat.com Sat Apr 23 22:15:48 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 23 Apr 2005 17:15:48 -0500 Subject: Fedora Extras: missing bugzilla components In-Reply-To: <1114284672.23930.12.camel@bobcat.mine.nu> References: <20050422140209.10e07ee7.bugs.michael@gmx.net> <1114284672.23930.12.camel@bobcat.mine.nu> Message-ID: <1114294548.18906.7.camel@localhost.localdomain> On Sat, 2005-04-23 at 22:31 +0300, Ville Skytt? wrote: > On Fri, 2005-04-22 at 14:02 +0200, Michael Schwendt wrote: > > 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 > > > > ogmtools > > Not needed, it's on its way out due to legal concerns. > http://fedoraproject.org/wiki/Extras_2fCVSSyncNeeded I don't know the legal concerns, but you probably want to make sure that entire module gets deleted (and any sources in the lookaside cache). ~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 wtogami at redhat.com Sun Apr 24 11:14:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 24 Apr 2005 01:14:53 -1000 Subject: /etc key location auto-migration Message-ID: <426B7FAD.7040807@redhat.com> Now that we have moved a bunch of packages keys or certs from somewhere in /usr to somewhere in /etc, shouldn't we also modify those packages %post to conditionally auto-migrate those keys/certs? Without auto-migration there will undoubtedly be many complaints and bug reports from people who upgrade like "FC4 broke SSL foo!" Conditional auto-migration would need to be carefully implemented and tested because it can be complicated. For example in some cases it would need to perform string-replacement in config files to point at the new key/cert location. In other cases it would *copy* keys/certs to new locations, but only if old location contains custom (non-packaged) keys/certs, and the new location does NOT contain custom files (files deposited prior to %post by the package update). How the heck would this be implemented (you may NOT run rpm during %post)? Is there any simpler algorithm that does the right thing? After things are copied, it would need to check/correct file permissions to make sure things are safe. In any case I'm convinced that auto-migration needs to happen, it will just be painful to implement correctly. First step is listing which packages need to be modified in this way? Warren Togami wtogami at redhat.com From tmraz at redhat.com Sun Apr 24 11:32:14 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Sun, 24 Apr 2005 13:32:14 +0200 Subject: /usr/share/ssl moved In-Reply-To: <1114122577.5886.43.camel@perun.redhat.usu> References: <1114122577.5886.43.camel@perun.redhat.usu> Message-ID: <1114342334.5868.0.camel@perun.redhat.usu> On Fri, 2005-04-22 at 00:29 +0200, Tomas Mraz wrote: > This is a result of the change discussed on this list. > > In the openssl-0.9.7f-4 the /usr/share/ssl contents is moved to > /etc/pki/tls and /etc/pki/CA. > > The remaining files in the /usr/share/ssl directory are owned by dovecot > package which should be changed appropriately. Also the selinux policies should be modified to point to the correct files. -- Tomas Mraz From jdennis at redhat.com Sun Apr 24 13:43:13 2005 From: jdennis at redhat.com (John Dennis) Date: Sun, 24 Apr 2005 09:43:13 -0400 Subject: /etc key location auto-migration In-Reply-To: <426B7FAD.7040807@redhat.com> References: <426B7FAD.7040807@redhat.com> Message-ID: <1114350194.1353.115.camel@localhost.localdomain> On Sun, 2005-04-24 at 01:14 -1000, Warren Togami wrote: > Now that we have moved a bunch of packages keys or certs from somewhere > in /usr to somewhere in /etc, shouldn't we also modify those packages > %post to conditionally auto-migrate those keys/certs? Without > auto-migration there will undoubtedly be many complaints and bug reports > from people who upgrade like "FC4 broke SSL foo!" > > Conditional auto-migration would need to be carefully implemented and > tested because it can be complicated. For example in some cases it > would need to perform string-replacement in config files to point at the > new key/cert location. > > In other cases it would *copy* keys/certs to new locations, but only if > old location contains custom (non-packaged) keys/certs, and the new > location does NOT contain custom files (files deposited prior to %post > by the package update). How the heck would this be implemented (you may > NOT run rpm during %post)? Is there any simpler algorithm that does the > right thing? This is effectively what I implemented in the two packages (cyrus-imapd, dovecot) I updated, albeit a bit simplier. The %post checks if a key file exists in the old location but not the new location. If so it moves the key file(s) to the new location. Then %post continues to do what it always did, check for a key file in the cannonical location, if it does not exist it generates a generic key. This does not attempt to identify if the key was a custom key, however I don't that matters, we only care if a key was in use in the old location. However, what can screw up, and I'm not really sure if there is a solution to this or not, is the %config(noreplace) file attribute on the the config file that has the key location in it. When the new rpm installs it comes with a config file that has been updated with the new location. However, if that file has been modified its not going to be replaced and there is going to be a mismatch. If the file has not been modified then everything works. I did test the key migration in the packages I own and modulo prior editing of the config file by the user it seems to do what you want. Other than release notes or adding something to /usr/doc/ I'm not sure how to handle the modified config file case. Suggestions? We could edit the config file that was preserved but I think that might be considered evil. > After things are copied, it would need to check/correct file permissions > to make sure things are safe. > > In any case I'm convinced that auto-migration needs to happen, it will > just be painful to implement correctly. First step is listing which > packages need to be modified in this way? I believe: cyrus-imapd dovecot httpd postfix (maybe?) -- John Dennis From wtogami at redhat.com Sun Apr 24 21:05:31 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 24 Apr 2005 11:05:31 -1000 Subject: /usr/share/ssl moved In-Reply-To: <1114342334.5868.0.camel@perun.redhat.usu> References: <1114122577.5886.43.camel@perun.redhat.usu> <1114342334.5868.0.camel@perun.redhat.usu> Message-ID: <426C0A1B.3070004@redhat.com> Tomas Mraz wrote: > On Fri, 2005-04-22 at 00:29 +0200, Tomas Mraz wrote: > >>This is a result of the change discussed on this list. >> >>In the openssl-0.9.7f-4 the /usr/share/ssl contents is moved to >>/etc/pki/tls and /etc/pki/CA. >> >>The remaining files in the /usr/share/ssl directory are owned by dovecot >>package which should be changed appropriately. > > > Also the selinux policies should be modified to point to the correct > files. > File a bug for each location to be sure it happens. Warren From jorton at redhat.com Mon Apr 25 12:27:56 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 25 Apr 2005 13:27:56 +0100 Subject: /etc key location auto-migration In-Reply-To: <426B7FAD.7040807@redhat.com> References: <426B7FAD.7040807@redhat.com> Message-ID: <20050425122756.GA22792@redhat.com> On Sun, Apr 24, 2005 at 01:14:53AM -1000, Warren Togami wrote: > Now that we have moved a bunch of packages keys or certs from somewhere > in /usr to somewhere in /etc, shouldn't we also modify those packages > %post to conditionally auto-migrate those keys/certs? Without > auto-migration there will undoubtedly be many complaints and bug reports > from people who upgrade like "FC4 broke SSL foo!" What will RPM do when /usr/share/ssl changes from a directory to a symlink on an upgrade, if /usr/share/ssl contains non-package-managed files? Fail to create the symlink, I'd presume? In which case, old configurations will remain pointing at old files, so no migration is necessary. Of course, if people *want* to migrate their stuff over they can do that manually. I don't think %post scripts should go moving random user-controlled files around nor munging configurations because of this change. joe From skvidal at phy.duke.edu Mon Apr 25 12:37:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 25 Apr 2005 08:37:50 -0400 Subject: /etc key location auto-migration In-Reply-To: <20050425122756.GA22792@redhat.com> References: <426B7FAD.7040807@redhat.com> <20050425122756.GA22792@redhat.com> Message-ID: <1114432670.15223.30.camel@cutter> > What will RPM do when /usr/share/ssl changes from a directory to a > symlink on an upgrade, if /usr/share/ssl contains non-package-managed > files? Fail to create the symlink, I'd presume? In which case, old > configurations will remain pointing at old files, so no migration is > necessary. Of course, if people *want* to migrate their stuff over they > can do that manually. > > I don't think %post scripts should go moving random user-controlled > files around nor munging configurations because of this change. Agreed. I think this should be flagged in the release-notes but otherwise not an automated event. For things like ssl keys erring on the side of caution makes a lot of sense. -sv From jdennis at redhat.com Mon Apr 25 14:10:54 2005 From: jdennis at redhat.com (John Dennis) Date: Mon, 25 Apr 2005 10:10:54 -0400 Subject: /etc key location auto-migration In-Reply-To: <20050425122756.GA22792@redhat.com> Message-ID: > I don't think %post scripts should go moving random user-controlled > files around nor munging configurations because of this change. Fair enough, I think that is a valid policy. It doesn't address Warren's concern with things mysterously breaking on upgrade, that should not be taken lightly. From past experience with moving directories people will be upset and some will be quite vocal with their displeasure. However, at the moment I don't think we have robust solution, only a partial solution. It would be wonderful if rpm could issue warning messages that would be displayed during an anaconda install but I don't think we have that feature do we? Thus the best solution might be the most minimal, release note it and don't do anything in %post. Put on your nomex suits. (By the way this is is the reason I pushed back on making this directory change in the first place, because I knew there was going to be pain involved, but I still think ultimately it was the right decision) John Dennis From johnp at redhat.com Tue Apr 26 01:51:49 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 25 Apr 2005 21:51:49 -0400 Subject: Headsup on DBus changes Message-ID: <1114480309.6761.32.camel@remedyz.boston.redhat.com> I just built dbus-0.33 into CVS. No .so names have been changed in this release so the C API remains the same. However the Python API's have changed quite a bit. Anyone who uses the Python API should update their packages. I am available to look at code and help fix it. This will be the final major API update to DBus for FC4 and I don't expect the API to change very much in the FC5 time frame. I had requested all packages in core to start using Requires: dbus >= 0.32 sometime back so there should be no dependency problems. Please check your packages to make sure this is true. Thanks. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From jorton at redhat.com Tue Apr 26 10:07:43 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 26 Apr 2005 11:07:43 +0100 Subject: /etc key location auto-migration In-Reply-To: References: <20050425122756.GA22792@redhat.com> Message-ID: <20050426100742.GC16976@redhat.com> On Mon, Apr 25, 2005 at 10:10:54AM -0400, John Dennis wrote: > > I don't think %post scripts should go moving random user-controlled > > files around nor munging configurations because of this change. > > Fair enough, I think that is a valid policy. It doesn't address > Warren's concern with things mysterously breaking on upgrade, > that should not be taken lightly. From past experience with > moving directories people will be upset and some will be quite > vocal with their displeasure. However, at the moment I don't > think we have robust solution, only a partial solution. It > would be wonderful if rpm could issue warning messages that > would be displayed during an anaconda install but I don't > think we have that feature do we? Actually: I had presumed that /usr/share/ssl would become a symlink, but it isn't. So what will break? If a %config(noreplace) config file references an SSL certificate in /usr/share/ssl/* which is not under package management, then that should be fine over an upgrade, since both the cert and the config file will remain intact. (that's the case for mod_ssl, at least) If you have a package-managed SSL certificate in /usr/share/ssl which is considered as throw-away and have it %ghosted (though this seems pretty questionable behaviour), you can make upgrades work by marking the config file which references it as %config-not-noreplace for FC4 final. joe From mattdm at mattdm.org Tue Apr 26 18:35:53 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 26 Apr 2005 14:35:53 -0400 Subject: Fedora Legacy, and What's Happening to *Your* FC2 Bugs.... In-Reply-To: <20050414161815.GA15677@jadzia.bu.edu> References: <20050414161815.GA15677@jadzia.bu.edu> Message-ID: <20050426183553.GA28034@jadzia.bu.edu> On Thu, Apr 14, 2005 at 12:18:15PM -0400, Matthew Miller wrote: > of "security". For the rest, I propose to mark ALL still-open FC2 bugs > as "NEEDINFO", with the following message: [...] As you may have noticed, I did this this morning. Thanks everyone for helping clean up the resulting spew. I strongly believe Fedora in general will be better off with some more of this. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From jdennis at redhat.com Tue Apr 26 21:20:26 2005 From: jdennis at redhat.com (John Dennis) Date: Tue, 26 Apr 2005 17:20:26 -0400 Subject: where 'o where to store certificates and keys In-Reply-To: <20050420223451.GE6644@devserv.devel.redhat.com> References: <1113941222.10777.58.camel@localhost.localdomain> <20050419222129.GA12387@redhat.com> <20050420164220.GA28313@nostromo.devel.redhat.com> <1114024136.10805.14.camel@localhost.localdomain> <20050420223451.GE6644@devserv.devel.redhat.com> Message-ID: <1114550426.14533.104.camel@finch.boston.redhat.com> On Wed, 2005-04-20 at 18:34 -0400, Alan Cox wrote: > On Wed, Apr 20, 2005 at 03:08:56PM -0400, John Dennis wrote: > > On Wed, 2005-04-20 at 12:42 -0400, Bill Nottingham wrote: > > > I'd think /etc/pki is more practical. > > > > Done, the name is chosen and the directory /etc/pki has been added > > making its appearance in filesystem-2.3.2-1. > > Cool - is it worth submitting that proposal to the FSSTND people ? Its > a multi-vendor issue and "where to put keys" will become an app issue more > and more over time. I promised I would do this and I followed up right away. I got the following response today from Thorsten Kukuk at SuSE on the freestandards-fhs-discuss at lists.sourceforge.net list where I had posted. I'm sharing this folks here in fedora land. Active discussion of this should probably take place on the FHS mailing list (above) and not a fedora specific list. I will try to be a bridge for simple issues. John -------------------------------------------------------------- Hi, I like the ida and SuSE/Novell is willing to follow such a specification in our next products, too. I added the comments of some of our developers below. On Thu, Apr 21, John Dennis wrote: > We propose (and actually have just implemented in Fedora Core 4) that > the directory /etc/pki (for Public Key Infrastructure) be created as a > root location for keys and certificates. It is recommended that each > service create a subdirectory named after itself under /etc/pki and that > it store its certificates, keys, etc. in its own subdirectory > under /etc/pki. [Some developers suggested to use /etc/ssl, since this is what OpenSSL already uses]. In general a good idea. We have to differ between two types of certificates. 1. The Server Certificate (and private Key) for a service (like http server, mail server, vpn, etc.) 2. A set of trusted (root) CA Certificates (and corresponding CRLs). Also one very common scenario is, that there is one server certificate for all services (or more that one) on a host. I do not know if it is required to have more than one set of trusted CA certificate. In case of doubt the answer is yes:-) Openssl has a default for this directory to /usr/ssl/certs/ . I think with the following proposal we could achieve the above topics. /etc/pki/ common/ trustedCerts/ serverCert/ / trustedCerts/ serverCert/ "common" directory: used, if an administrator wants to use server certificates and/or trusted CA certificates for more than one service "" directory: used for a dedicated service "trustedCerts" directory: used for a set of trusted (root) CA certificates and CRLs "serverCert" directory: used for the server certificate and the private key --- Another comment was: One should also distinguish between: - - the "default"/out-of-the-box use of /etc/ssl/certs to contain all kinds of root CA certificates so that SSL client certificates can be verified - - the PKI use of OpenSSL where you generate your own certs. In an ideal world, I don't want my CA's certificates to be mixed with those root certificates, at least not physically. In my setup, I put them in a seperate subdirectory "own" (could also be named "pki" or "default_CA") and put symlinks into /etc/ssl/certs instead. One could of course also turn it around: use /etc/ssl/certs for own certificates and put the root certs in /etc/ssl/certs/root-CAs or something like that. As for the name /etc/pki itself, I prefer /etc/ssl since this is a more specific term (= a directory related to OpenSSL) than PKI (= a particular use of OpenSSL). > [...] > Please note, the keys and certificates which would reside in /etc/pki > are for system supplied services (e.g. mail servers, web servers, ssh, > etc.). It is not intended as a repository for per user keys. A similar directory layout could be created in ~/.local or ~/.ssl or ~/.pki ... Thorsten From oliver at linux-kernel.at Fri Apr 29 07:04:49 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Apr 2005 09:04:49 +0200 Subject: Version problem Message-ID: <200504290704.j3T740tl014853@mail.linux-kernel.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! First of all: Might be a silly question, but I'd like to see what the _best_ or the Fedora-like solution in this case is... I have the following problem. Current verel I have is 0.84rc2-1, new verel is 0.84-1. But trying to install the new rpms with rpm -Fvh fails (or better said: rpm does nothing), because RPM thinks 0.84rc2-1 is newer than 0.84-1. What is the best solution to make the 0.84-1 the newer version? I could use epoch for this, but I don't think that this is the best solution, is it!? Any ideas/solutions are welcome! Best, Oliver - - linux-kernel.at Oliver Falk UNIX/Linux Systems Administrator Autonomy Information Engineer -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQnHckcVjeRnvJSlDEQKrpACdE2H5iJkimMwA6u3bc6wEc2awi4sAoJbf RAtmKj7ItMubpiV+Sv0euoiz =VIgp -----END PGP SIGNATURE----- From ivazquez at ivazquez.net Fri Apr 29 07:50:44 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 29 Apr 2005 03:50:44 -0400 Subject: Version problem In-Reply-To: <200504290704.j3T740tl014853@mail.linux-kernel.at> References: <200504290704.j3T740tl014853@mail.linux-kernel.at> Message-ID: <1114761044.5061.54.camel@ignacio.ignacio.lan> On Fri, 2005-04-29 at 09:04 +0200, Oliver Falk wrote: > Hi! > > First of all: > Might be a silly question, but I'd like to see what the _best_ or the > Fedora-like solution in this case is... > > I have the following problem. Current verel I have is 0.84rc2-1, new verel > is > 0.84-1. But trying to install the new rpms with rpm -Fvh fails (or better > said: > rpm does nothing), because RPM thinks 0.84rc2-1 is newer than 0.84-1. What > is > the best solution to make the 0.84-1 the newer version? I could use epoch > for > this, but I don't think that this is the best solution, is it!? That's what Epoch was made for. The ideal solution would be if the previous package had been 0.84-1-rc2, then the new package could be 0.84-2. Oh well. -- 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 oliver at linux-kernel.at Fri Apr 29 07:54:30 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Apr 2005 09:54:30 +0200 Subject: Version problem In-Reply-To: <1114761044.5061.54.camel@ignacio.ignacio.lan> Message-ID: <200504290753.j3T7rg3e025046@mail.linux-kernel.at> Hi Ignacio! Ignacio Vazquez-Abrams wrote: > On Fri, 2005-04-29 at 09:04 +0200, Oliver Falk wrote: > > First of all: > > Might be a silly question, but I'd like to see what the > > _best_ or the > > Fedora-like solution in this case is... > > > > I have the following problem. Current verel I have is > > 0.84rc2-1, new > > verel is 0.84-1. But trying to install the new rpms with rpm -Fvh > > fails (or better > > said: > > rpm does nothing), because RPM thinks 0.84rc2-1 is newer > > than 0.84-1. > > What is the best solution to make the 0.84-1 the newer version? I > > could use epoch for this, but I don't think that this is the best > > solution, is it!? > > That's what Epoch was made for. OK, so I'll use Epoch for this (well, allready did :-) ). > The ideal solution would be > if the previous package had been 0.84-1-rc2, then the new > package could be 0.84-2. Oh well. I'll remind myself about this as soon as I have 0.85 rc1 or somethin' like that. :-) Thanks, Oliver From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Apr 29 10:51:40 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 29 Apr 2005 12:51:40 +0200 Subject: Version problem In-Reply-To: <200504290753.j3T7rg3e025046@mail.linux-kernel.at> References: <1114761044.5061.54.camel@ignacio.ignacio.lan> <200504290753.j3T7rg3e025046@mail.linux-kernel.at> Message-ID: <20050429125140.0e70ed4e@python2> Oliver Falk wrote : > > That's what Epoch was made for. > > OK, so I'll use Epoch for this (well, allready did :-) ). Argh. Please try to not introduce any unnecessary initial epochs into Fedora Extras packages! > > The ideal solution would be > > if the previous package had been 0.84-1-rc2, then the new > > package could be 0.84-2. Oh well. > > I'll remind myself about this as soon as I have 0.85 rc1 or somethin' like > that. :-) It's all explained here : http://fedoraproject.org/wiki/PackageNamingGuidelines Obviously, one could consider "it's too late", but if the package with version "0.84rc2" wasn't too widespread, I'd really suggest you don't use epoch and live with the minor breakage that the non-upgradability (until 0.85 something is released, that is) will cause. And yes, I'm saying that because "0.82rc2" for version is contrary to the guidelines, and because *I*'m your sponsor for Extras ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.85 1.77 1.53 From oliver at linux-kernel.at Fri Apr 29 11:06:59 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Fri, 29 Apr 2005 13:06:59 +0200 Subject: Version problem In-Reply-To: <20050429125140.0e70ed4e@python2> Message-ID: <200504291106.j3TB69t1018230@mail.linux-kernel.at> Matthias Saou wrote: > Oliver Falk wrote : > > > That's what Epoch was made for. > > > > OK, so I'll use Epoch for this (well, allready did :-) ). > > Argh. Please try to not introduce any unnecessary initial > epochs into Fedora Extras packages! Don't be afraid, I'm not goin' to do that! > > > The ideal solution would be > > > if the previous package had been 0.84-1-rc2, then the new package > > > could be 0.84-2. Oh well. > > > > I'll remind myself about this as soon as I have 0.85 rc1 or > > somethin' like that. :-) > > It's all explained here : > > http://fedoraproject.org/wiki/PackageNamingGuidelines Arg. Seems I missed that section :-( > Obviously, one could consider "it's too late", but if the > package with version "0.84rc2" wasn't too widespread, I'd > really suggest you don't use epoch and live with the minor > breakage that the non-upgradability (until > 0.85 something is released, that is) will cause. It was a local package, that was never commited to Extras, as I had no time to do that and it's only needed at my local box (currently). > And yes, I'm saying that because "0.82rc2" for version is > contrary to the guidelines, No I know! > and because *I*'m your sponsor for Extras ;-) Thanks a lot for have an eye on me :-) Best, Oliver From notting at redhat.com Fri Apr 29 16:17:40 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 29 Apr 2005 12:17:40 -0400 Subject: build for translations Message-ID: <20050429161740.GA11758@nostromo.devel.redhat.com> Note on the schedule at: http://fedora.redhat.com/participate/schedule/ 9 May: test3, translation build freeze (builds completed) So, if you've got a package on rhlinux.redhat.com that has community translations, please make sure that you get a version built that has the most up-to-date translations. Thanks, Bill