From rc040203 at freenet.de Tue Nov 1 03:27:00 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Nov 2005 04:27:00 +0100 Subject: Renaming a package Message-ID: <1130815621.5205.79.camel@mccallum.corsepiu.local> Hi, What is this recommended/nominal procedure to rename a package in FE's CVS? I could imagine 3 approaches: 1. I "cvs add" the "old-package" as "new-package", edit the files accordingly, then subsequently "cvs rm old-package". 2. Somebody with direct CVS repository moves the directories in CVS ("cp old-package new-package") and I edit the files after the directories have been moved. 3. I leave the directory names as they currently are ("old-package") and edit the files inside to build "new-package". Ralf From rc040203 at freenet.de Tue Nov 1 05:41:27 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 01 Nov 2005 06:41:27 +0100 Subject: Renaming a package In-Reply-To: <4366E396.5030307@poolshark.org> References: <1130815621.5205.79.camel@mccallum.corsepiu.local> <4366E396.5030307@poolshark.org> Message-ID: <1130823687.5205.130.camel@mccallum.corsepiu.local> On Mon, 2005-10-31 at 19:40 -0800, Denis Leroy wrote: > Ralf Corsepius wrote: > > Hi, > > > > What is this recommended/nominal procedure to rename a package in FE's > > CVS? > > > > I could imagine 3 approaches: > > > > 1. I "cvs add" the "old-package" as "new-package", edit the files > > accordingly, then subsequently "cvs rm old-package". > > I would recommend this, since this is the regular CVS approach. It's > important that the new-package CVS commit message includes a pointer to > the old name ("moved from old-package"), so that one is able to follow > this link to consult the CVS history of the file if necessary. By > removing the old-package files, and always using the -P (prune empty > directories) with cvs update, the old empty directory will be removed > automatically by CVS during the update. This way, you're loosing CVS history of the files being involved. Also, given the way FE's packages currently are implemented in CVS (using a CVS module for "common"), CVSROOT/modules could be a problem [1]. AFAIU, when you "cvs rm" all "old-package" subdirs, the corresponding "common" entry in "modules" will have to remain, i.e. 'cvs co -dP "old-package"' will always give you a package directory with a common/ subdirectory. > > 2. Somebody with direct CVS repository moves the directories in CVS > > ("cp old-package new-package") and I edit the files after the > > directories have been moved. > > This corrupts the CVS repository because one can no longer checkout an > older tree. Should be avoided. Well, right, it "corrupts" the CVS repository in the sense, you mention, however it doesn't corrupt the repository, in the sense of "rendering it technically unusable". On the other hand, it preserves CVS history of the renamed package. I.e. the old packages would still be present inside of CVS except that they would appear in a different directory upon checkouts. How about "copying the directories (instead of moving)" directly in CVS, and "untagging" all "inherited tags" in "new-package"? This way you'd not loose a package's history, and wouldn't "corrupt" the repository. CVSROOT/modules, would remain a problem. Ralf [1] CVSROOT/modules already is a problem elsewhere: GiNaC had been renamed into "ginac": ATM, in CVSROOT/modules, the GiNaC modules are being still mentioned, but the directory rpms/GiNaC/ seems to have been physically removed => Though GiNaC had been released, the corresponding CVS seems to be gone (corrupted CVS in your sense above). => cvs co GiNaC throws an error: # cvs co GiNaC cvs [checkout aborted]: there is no repository /cvs/extras/rpms/GiNaC From a.kurtz at hardsun.net Tue Nov 1 08:02:14 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Tue, 01 Nov 2005 00:02:14 -0800 Subject: Moving packages from extras to core In-Reply-To: <1129912233.13150.43.camel@greebo> References: <1129912233.13150.43.camel@greebo> Message-ID: <1130832134.27894.2.camel@rydia.hardsun.net> On Fri, 2005-10-21 at 18:30 +0200, Alexander Larsson wrote: > Also, how will this work wrt maintainership of the package? I'm fine > with owning this package inside redhat, but I don't want to steal it > from the current extras maintainer (cc:ed). I just needed it in core due > to the Avahi dependency. As the maintainer of libdaemon, if you'd like to handle it in Extras for FC3 and FC4, feel free. I took it over only because the prior maintainer's address was bouncing and I was attempting to get another package into Extras that needed an updated version. -- Aaron Kurtz From denis at poolshark.org Tue Nov 1 03:40:06 2005 From: denis at poolshark.org (Denis Leroy) Date: Mon, 31 Oct 2005 19:40:06 -0800 Subject: Renaming a package In-Reply-To: <1130815621.5205.79.camel@mccallum.corsepiu.local> References: <1130815621.5205.79.camel@mccallum.corsepiu.local> Message-ID: <4366E396.5030307@poolshark.org> Ralf Corsepius wrote: > Hi, > > What is this recommended/nominal procedure to rename a package in FE's > CVS? > > I could imagine 3 approaches: > > 1. I "cvs add" the "old-package" as "new-package", edit the files > accordingly, then subsequently "cvs rm old-package". I would recommend this, since this is the regular CVS approach. It's important that the new-package CVS commit message includes a pointer to the old name ("moved from old-package"), so that one is able to follow this link to consult the CVS history of the file if necessary. By removing the old-package files, and always using the -P (prune empty directories) with cvs update, the old empty directory will be removed automatically by CVS during the update. > 2. Somebody with direct CVS repository moves the directories in CVS > ("cp old-package new-package") and I edit the files after the > directories have been moved. This corrupts the CVS repository because one can no longer checkout an older tree. Should be avoided. From denis at poolshark.org Tue Nov 1 18:07:42 2005 From: denis at poolshark.org (Denis Leroy) Date: Tue, 01 Nov 2005 10:07:42 -0800 Subject: Renaming a package In-Reply-To: <1130823687.5205.130.camel@mccallum.corsepiu.local> References: <1130815621.5205.79.camel@mccallum.corsepiu.local> <4366E396.5030307@poolshark.org> <1130823687.5205.130.camel@mccallum.corsepiu.local> Message-ID: <4367AEEE.8050206@poolshark.org> Ralf Corsepius wrote: >On Mon, 2005-10-31 at 19:40 -0800, Denis Leroy wrote: > > >>Ralf Corsepius wrote: >> >> >>>Hi, >>> >>>What is this recommended/nominal procedure to rename a package in FE's >>>CVS? >>> >>>I could imagine 3 approaches: >>> >>>1. I "cvs add" the "old-package" as "new-package", edit the files >>>accordingly, then subsequently "cvs rm old-package". >>> >>> >>I would recommend this, since this is the regular CVS approach. It's >>important that the new-package CVS commit message includes a pointer to >>the old name ("moved from old-package"), so that one is able to follow >>this link to consult the CVS history of the file if necessary. By >>removing the old-package files, and always using the -P (prune empty >>directories) with cvs update, the old empty directory will be removed >>automatically by CVS during the update. >> >> >This way, you're loosing CVS history of the files being involved. > > No no you don't. You can rm a file, cvs remove it, and still acess its history with 'cvs log'. The history is merely split into 2 locations. That's why i was stressing that the log information should always mention the previous name and location. From skvidal at phy.duke.edu Wed Nov 2 17:03:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 02 Nov 2005 12:03:50 -0500 Subject: gnome question Message-ID: <1130951030.11708.5.camel@cutter> Hi, Some folks on IRC have been discussing whether or not we should push a gnome 2.14rc into core so we can have 2.14 in FC5 final. What do folks think. It would require a lag of FC5 out an extra month to get the final 2.14 release of gnome, though. so, thoughts? -sv From mclasen at redhat.com Wed Nov 2 17:05:47 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 02 Nov 2005 12:05:47 -0500 Subject: gnome question In-Reply-To: <1130951030.11708.5.camel@cutter> References: <1130951030.11708.5.camel@cutter> Message-ID: <1130951147.8430.9.camel@golem.boston.redhat.com> On Wed, 2005-11-02 at 12:03 -0500, seth vidal wrote: > Hi, > Some folks on IRC have been discussing whether or not we should push a > gnome 2.14rc into core so we can have 2.14 in FC5 final. > > What do folks think. It would require a lag of FC5 out an extra month to > get the final 2.14 release of gnome, though. > > so, thoughts? That is the plan From wtogami at redhat.com Wed Nov 2 17:06:01 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 02 Nov 2005 12:06:01 -0500 Subject: gnome question In-Reply-To: <1130951030.11708.5.camel@cutter> References: <1130951030.11708.5.camel@cutter> Message-ID: <4368F1F9.2090408@redhat.com> seth vidal wrote: > Hi, > Some folks on IRC have been discussing whether or not we should push a > gnome 2.14rc into core so we can have 2.14 in FC5 final. > > What do folks think. It would require a lag of FC5 out an extra month to > get the final 2.14 release of gnome, though. > > so, thoughts? > Last plans I heard discussed was the possibility of pushing GNOME 2.13 during the FC5 cycle. This may end up with RC in FC5 final, however if Fedora slips further we may end up with 2.14 final. Nothing is certain in plans yet. When I know more I'll update here. Warren From skvidal at phy.duke.edu Wed Nov 2 18:54:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 02 Nov 2005 13:54:33 -0500 Subject: gnome question In-Reply-To: <1130951147.8430.9.camel@golem.boston.redhat.com> References: <1130951030.11708.5.camel@cutter> <1130951147.8430.9.camel@golem.boston.redhat.com> Message-ID: <1130957673.11708.12.camel@cutter> On Wed, 2005-11-02 at 12:05 -0500, Matthias Clasen wrote: > On Wed, 2005-11-02 at 12:03 -0500, seth vidal wrote: > > Hi, > > Some folks on IRC have been discussing whether or not we should push a > > gnome 2.14rc into core so we can have 2.14 in FC5 final. > > > > What do folks think. It would require a lag of FC5 out an extra month to > > get the final 2.14 release of gnome, though. > > > > so, thoughts? > > That is the plan > Cool. Is this plan posted anywhere? Thorsten was asking and those of us on the outside of redhat.com didn't know what the plan was. -sv From dennis at ausil.us Wed Nov 2 19:15:38 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 2 Nov 2005 13:15:38 -0600 Subject: gnome question In-Reply-To: <1130951030.11708.5.camel@cutter> References: <1130951030.11708.5.camel@cutter> Message-ID: <200511021315.38161.dennis@ausil.us> On Wednesday 02 November 2005 11:03, seth vidal wrote: > Hi, > Some folks on IRC have been discussing whether or not we should push a > gnome 2.14rc into core so we can have 2.14 in FC5 final. > > What do folks think. It would require a lag of FC5 out an extra month to > get the final 2.14 release of gnome, though. > > so, thoughts? > > -sv I would really hope not. Dennis From mclasen at redhat.com Wed Nov 2 19:15:54 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 02 Nov 2005 14:15:54 -0500 Subject: gnome question In-Reply-To: <1130957673.11708.12.camel@cutter> References: <1130951030.11708.5.camel@cutter> <1130951147.8430.9.camel@golem.boston.redhat.com> <1130957673.11708.12.camel@cutter> Message-ID: <1130958954.8430.12.camel@golem.boston.redhat.com> On Wed, 2005-11-02 at 13:54 -0500, seth vidal wrote: > On Wed, 2005-11-02 at 12:05 -0500, Matthias Clasen wrote: > > On Wed, 2005-11-02 at 12:03 -0500, seth vidal wrote: > > > Hi, > > > Some folks on IRC have been discussing whether or not we should push a > > > gnome 2.14rc into core so we can have 2.14 in FC5 final. > > > > > > What do folks think. It would require a lag of FC5 out an extra month to > > > get the final 2.14 release of gnome, though. > > > > > > so, thoughts? > > > > That is the plan > > > > Cool. Is this plan posted anywhere? Thorsten was asking and those of us > on the outside of redhat.com didn't know what the plan was. > No, sorry, it hasn't been posted anywhere yet. This is a fairly recent change. Where would be the right place to post this kind of information ? Matthias From sundaram at redhat.com Wed Nov 2 19:19:59 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 03 Nov 2005 00:49:59 +0530 Subject: gnome question In-Reply-To: <1130958954.8430.12.camel@golem.boston.redhat.com> References: <1130951030.11708.5.camel@cutter> <1130951147.8430.9.camel@golem.boston.redhat.com> <1130957673.11708.12.camel@cutter> <1130958954.8430.12.camel@golem.boston.redhat.com> Message-ID: <4369115F.3080309@redhat.com> Hi >>No, sorry, it hasn't been posted anywhere yet. This is a fairly recent >>change. Where would be the right place to post this kind of >>information ? >> >>Matthias >> >> fedora-test list. You can also update http://fedoraproject.org/wiki/FC5Future regards Rahul From fedora at leemhuis.info Wed Nov 2 19:24:42 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 Nov 2005 20:24:42 +0100 Subject: gnome question In-Reply-To: <1130957673.11708.12.camel@cutter> References: <1130951030.11708.5.camel@cutter> <1130951147.8430.9.camel@golem.boston.redhat.com> <1130957673.11708.12.camel@cutter> Message-ID: <1130959482.3309.35.camel@localhost.localdomain> Am Mittwoch, den 02.11.2005, 13:54 -0500 schrieb seth vidal: > On Wed, 2005-11-02 at 12:05 -0500, Matthias Clasen wrote: > > On Wed, 2005-11-02 at 12:03 -0500, seth vidal wrote: > > > Some folks on IRC have been discussing whether or not we should push a > > > gnome 2.14rc into core so we can have 2.14 in FC5 final. > > > > > > What do folks think. It would require a lag of FC5 out an extra month to > > > get the final 2.14 release of gnome, though. > > > so, thoughts? > > That is the plan > Cool. Is this plan posted anywhere? http://www.fedoraproject.org/wiki/FC5Future would be the right place afaics I'll add a small note there after I finish this mail but we should update it after something is definitive. > Thorsten Yes, I was the idiot ;-) > was asking and those of us > on the outside of redhat.com didn't know what the plan was. Actually, *if* we have (another) lag of FC5 we should soon adjust our schedule IMHO -- otherwise we might soon see websites that write "Red Hat/Fedora is like Mickysoft -- they both always break their release schedule for their operating system" ;-) /me runs -- Thorsten Leemhuis From sopwith at redhat.com Thu Nov 3 20:37:00 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 3 Nov 2005 15:37:00 -0500 (EST) Subject: CVS server maintenance Message-ID: cvs.fedora.redhat.com will be down for an hour maximum. I have to change GIDs of some groups to avoid future problems. Best, -- Elliot From sopwith at redhat.com Thu Nov 3 20:57:50 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 3 Nov 2005 15:57:50 -0500 (EST) Subject: CVS server maintenance In-Reply-To: References: Message-ID: On Thu, 3 Nov 2005, Elliot Lee wrote: > cvs.fedora.redhat.com will be down for an hour maximum. I have to change > GIDs of some groups to avoid future problems. And it's back! -- Elliot From wtogami at redhat.com Thu Nov 3 21:35:39 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 03 Nov 2005 16:35:39 -0500 Subject: FC5test1 devel freeze, November 14th Message-ID: <436A82AB.9070701@redhat.com> If you are involved in the development of Fedora Core as a packager, here is information that will be relevant to you. FC5test1 devel freeze now November 14th ======================================= Rawhide is undergoing a large amount of churn as we are preparing for the switch from monolithic to modular X. Modular X is one of the larger and more important changes of FC5, meaning we need extensive test exposure. For this reason the test1 devel freeze has been postponed until November 14th. http://fedora.redhat.com/participate/schedule/ Fedora Core 5 Development Schedule has been updated. http://fedoraproject.org/wiki/DocsProject/Schedule Participants of the Fedora Documentation project have an updated schedule here for release notes content and translation deadlines. If you are brave and willing to deal with the unpredictability of rawhide, your assistance in testing, reporting and fixing bugs as we approach the November 14th devel freeze would be greatly appreciated. Modular X requires FE5 Fixes ============================ The major change created by modular X is that XFree86-devel and xorg-x11-devel are no longer provided in the buildroot. All packages in both Core and Extras are now expected to have BuildRequires on the individual libFOO-devel packages of the newly split modular X. In order to ease into this, the current monolithic xorg-x11 package in rawhide contains many virtual provides for libFOO-devel. Modular X itself will hit rawhide *REAL SOON NOW*. In addition to the lack of XFree86-devel and xorg-x11-devel, /usr/X11R6/lib will disappear so packages that previously hardcoded this path will need to be fixed. mharris has indicated that he is preparing a webpage with further details about modular X and things that need to be fixed. Unfortunately FC5 rawhide will not be consistent and suitable for many FE5 builds until the entire modular X tree is pushed. But when it does happen, everyone's help will be needed to find problems in Core and rebuild packages in Extras in order to rapidly prepare everything for test1. Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Fri Nov 4 00:54:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Nov 2005 19:54:41 -0500 Subject: sandbox targets Message-ID: <1131065681.20403.57.camel@cutter> Hey, I was wondering if it might be useful if we made -sandbox targets for all of the current fedora extras targets. The goal would be so that a package maintainer could request a build of their package that was not for release. The package would be submitted to the buildsystem and build in the same environment, so everything would be the same, BUT it would sit in another dir on buildsys.fedoraproject.org and never be released to the general public. I'm thinking it would allow me to test out the build in a chroot w/o having to set one up on their own machine. The sandbox repo would have a short timespan on it's life. Packages would last there for something like 5-7 days then be tmpwatch reaped. I'm thinking the targets would just be named like: fedora-4-extras-sandbox. So what do people think? Should we make it so? -sv From jspaleta at gmail.com Fri Nov 4 01:07:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 3 Nov 2005 20:07:02 -0500 Subject: sandbox targets In-Reply-To: <1131065681.20403.57.camel@cutter> References: <1131065681.20403.57.camel@cutter> Message-ID: <604aa7910511031707s5447b7b8tff2d3b30e332c2f2@mail.gmail.com> On 11/3/05, seth vidal wrote: > So what do people think? Should we make it so? I'd certaintly use that option for anything i submitted into the system from this point just as a sanity check on functionality before going to publish. One thing to watch out for... if sandbox builds are a very popular feature...you might consider sandbox builds be given lower priority instead of fifowith to-be-published packages. I'd have to see a lot of sandbox builds que up and clog the buildhosts. But this is obviously a secondary issue which might never need to be addressed. -jef From gemi at bluewin.ch Fri Nov 4 01:42:27 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 04 Nov 2005 02:42:27 +0100 Subject: sandbox targets In-Reply-To: <1131065681.20403.57.camel@cutter> References: <1131065681.20403.57.camel@cutter> Message-ID: <1131068547.13629.2.camel@scriabin.tannenrauch.ch> On Thu, 2005-11-03 at 19:54 -0500, seth vidal wrote: > Hey, > I was wondering if it might be useful if we made -sandbox targets for > all of the current fedora extras targets. The goal would be so that a > package maintainer could request a build of their package that was not > for release. > > The package would be submitted to the buildsystem and build in the same > environment, so everything would be the same, BUT it would sit in > another dir on buildsys.fedoraproject.org and never be released to the > general public. > > I'm thinking it would allow me to test out the build in a chroot w/o > having to set one up on their own machine. The sandbox repo would have a > short timespan on it's life. Packages would last there for something > like 5-7 days then be tmpwatch reaped. > > I'm thinking the targets would just be named like: > fedora-4-extras-sandbox. > > > So what do people think? Should we make it so? > > -sv Maybe one could request a build for the HEAD of CVS, without tagging, then one could make changes to the spec files without bumbing up the release tag. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From skvidal at phy.duke.edu Fri Nov 4 01:46:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Nov 2005 20:46:39 -0500 Subject: sandbox targets In-Reply-To: <1131068547.13629.2.camel@scriabin.tannenrauch.ch> References: <1131065681.20403.57.camel@cutter> <1131068547.13629.2.camel@scriabin.tannenrauch.ch> Message-ID: <1131068799.20403.63.camel@cutter> > Maybe one could request a build for the HEAD of CVS, without > tagging, then one could make changes to the spec files > without bumbing up the release tag. You can't request a build right now w/o a tag. Moreover doesn't that get pretty odd when we think about requesting a sandbox build for the non-development distro targets? -sv From rc040203 at freenet.de Fri Nov 4 03:02:59 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 04 Nov 2005 04:02:59 +0100 Subject: FC5test1 devel freeze, November 14th In-Reply-To: <436A82AB.9070701@redhat.com> References: <436A82AB.9070701@redhat.com> Message-ID: <1131073379.19437.294.camel@mccallum.corsepiu.local> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote: > If you are involved in the development of Fedora Core as a packager, > here is information that will be relevant to you. > Modular X requires FE5 Fixes > ============================ > The major change created by modular X is that XFree86-devel and > xorg-x11-devel are no longer provided in the buildroot. All packages in > both Core and Extras are now expected to have BuildRequires on the > individual libFOO-devel packages of the newly split modular X. In order > to ease into this, the current monolithic xorg-x11 package in rawhide > contains many virtual provides for libFOO-devel. Modular X itself will > hit rawhide *REAL SOON NOW*. Will we see corresponding "Provides: libFOO-devel = x.y.z" being added to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward compatibility? Ralf From jwboyer at jdub.homelinux.org Fri Nov 4 03:33:59 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 03 Nov 2005 21:33:59 -0600 Subject: sandbox targets In-Reply-To: <604aa7910511031707s5447b7b8tff2d3b30e332c2f2@mail.gmail.com> References: <1131065681.20403.57.camel@cutter> <604aa7910511031707s5447b7b8tff2d3b30e332c2f2@mail.gmail.com> Message-ID: <1131075239.30608.7.camel@yoda.jdub.homelinux.org> On Thu, 2005-11-03 at 20:07 -0500, Jeff Spaleta wrote: > On 11/3/05, seth vidal wrote: > > So what do people think? Should we make it so? > > I'd certaintly use that option for anything i submitted into the > system from this point just as a sanity check on functionality before > going to publish. Ditto. One could even use it for *gasp* putting test packages out there for bug fixes. I really like this sandbox idea. > > One thing to watch out for... if sandbox builds are a very popular > feature...you might consider sandbox builds be given lower priority > instead of fifowith to-be-published packages. I'd have to see a lot > of sandbox builds que up and clog the buildhosts. But this is > obviously a secondary issue which might never need to be addressed. I think this is a valid point. It's better to at least think about it now rather than try to fix it when the buildsys is over-whelmed. This is a case where being proactive will probably work out better than reactive. josh From skvidal at phy.duke.edu Fri Nov 4 03:39:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 03 Nov 2005 22:39:08 -0500 Subject: sandbox targets In-Reply-To: <1131075239.30608.7.camel@yoda.jdub.homelinux.org> References: <1131065681.20403.57.camel@cutter> <604aa7910511031707s5447b7b8tff2d3b30e332c2f2@mail.gmail.com> <1131075239.30608.7.camel@yoda.jdub.homelinux.org> Message-ID: <1131075548.20403.65.camel@cutter> On Thu, 2005-11-03 at 21:33 -0600, Josh Boyer wrote: > On Thu, 2005-11-03 at 20:07 -0500, Jeff Spaleta wrote: > > On 11/3/05, seth vidal wrote: > > > So what do people think? Should we make it so? > > > > I'd certaintly use that option for anything i submitted into the > > system from this point just as a sanity check on functionality before > > going to publish. > > Ditto. One could even use it for *gasp* putting test packages out there > for bug fixes. I really like this sandbox idea. > > > > > One thing to watch out for... if sandbox builds are a very popular > > feature...you might consider sandbox builds be given lower priority > > instead of fifowith to-be-published packages. I'd have to see a lot > > of sandbox builds que up and clog the buildhosts. But this is > > obviously a secondary issue which might never need to be addressed. > > I think this is a valid point. It's better to at least think about it > now rather than try to fix it when the buildsys is over-whelmed. This > is a case where being proactive will probably work out better than > reactive. > I disagree - overthinking it and adding a bunch of scheduler priority mechanisms in the queuer will just make more work. Let's go for low hanging fruit and see if we actually have a problem at all. -sv From jwboyer at jdub.homelinux.org Fri Nov 4 04:00:24 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 03 Nov 2005 22:00:24 -0600 Subject: sandbox targets In-Reply-To: <1131075548.20403.65.camel@cutter> References: <1131065681.20403.57.camel@cutter> <604aa7910511031707s5447b7b8tff2d3b30e332c2f2@mail.gmail.com> <1131075239.30608.7.camel@yoda.jdub.homelinux.org> <1131075548.20403.65.camel@cutter> Message-ID: <1131076824.30608.13.camel@yoda.jdub.homelinux.org> On Thu, 2005-11-03 at 22:39 -0500, seth vidal wrote: > On Thu, 2005-11-03 at 21:33 -0600, Josh Boyer wrote: > > On Thu, 2005-11-03 at 20:07 -0500, Jeff Spaleta wrote: > > > On 11/3/05, seth vidal wrote: > > > > So what do people think? Should we make it so? > > > > > > I'd certaintly use that option for anything i submitted into the > > > system from this point just as a sanity check on functionality before > > > going to publish. > > > > Ditto. One could even use it for *gasp* putting test packages out there > > for bug fixes. I really like this sandbox idea. > > > > > > > > One thing to watch out for... if sandbox builds are a very popular > > > feature...you might consider sandbox builds be given lower priority > > > instead of fifowith to-be-published packages. I'd have to see a lot > > > of sandbox builds que up and clog the buildhosts. But this is > > > obviously a secondary issue which might never need to be addressed. > > > > I think this is a valid point. It's better to at least think about it > > now rather than try to fix it when the buildsys is over-whelmed. This > > is a case where being proactive will probably work out better than > > reactive. > > > > I disagree - overthinking it and adding a bunch of scheduler priority > mechanisms in the queuer will just make more work. Let's go for low > hanging fruit and see if we actually have a problem at all. *shrug* Fair enough. Without knowing the real mechanics behind it, I assume that fixing it if needs be wouldn't be too hard? People always find creative uses for things... josh From wtogami at redhat.com Fri Nov 4 04:03:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 03 Nov 2005 23:03:53 -0500 Subject: sandbox targets In-Reply-To: <1131065681.20403.57.camel@cutter> References: <1131065681.20403.57.camel@cutter> Message-ID: <436ADDA9.6050109@redhat.com> seth vidal wrote: > > I'm thinking the targets would just be named like: > fedora-4-extras-sandbox. > > > So what do people think? Should we make it so? > Great idea, but could we call it -scratch instead? That is what we call it in beehive in Red Hat, so it would be less confusing to our feeble minds. Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Fri Nov 4 05:00:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 04 Nov 2005 00:00:37 -0500 Subject: sandbox targets In-Reply-To: <436ADDA9.6050109@redhat.com> References: <1131065681.20403.57.camel@cutter> <436ADDA9.6050109@redhat.com> Message-ID: <1131080438.20403.70.camel@cutter> On Thu, 2005-11-03 at 23:03 -0500, Warren Togami wrote: > seth vidal wrote: > > > > I'm thinking the targets would just be named like: > > fedora-4-extras-sandbox. > > > > > > So what do people think? Should we make it so? > > > > Great idea, but could we call it -scratch instead? That is what we call > it in beehive in Red Hat, so it would be less confusing to our feeble minds. > awww - but the word sandbox is so much cuter. :) scratch is fine - just worried about all the satanic references offending someone. ;) -sv From jspaleta at gmail.com Fri Nov 4 05:14:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 Nov 2005 00:14:22 -0500 Subject: sandbox targets In-Reply-To: <1131080438.20403.70.camel@cutter> References: <1131065681.20403.57.camel@cutter> <436ADDA9.6050109@redhat.com> <1131080438.20403.70.camel@cutter> Message-ID: <604aa7910511032114y7e259f10vcb4fe77fb6b40cad@mail.gmail.com> On 11/4/05, seth vidal wrote: > awww - but the word sandbox is so much cuter. :) litterbox would ring more true. -jef From Christian.Iseli at licr.org Fri Nov 4 07:49:52 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Fri, 04 Nov 2005 08:49:52 +0100 Subject: sandbox targets In-Reply-To: Your message of "Thu, 03 Nov 2005 19:54:41 EST." <1131065681.20403.57.camel@cutter> Message-ID: <200511040749.jA47nqmL018586@ludwig-alpha.unil.ch> skvidal at phy.duke.edu said: > So what do people think? I like it! Christian From nphilipp at redhat.com Fri Nov 4 16:24:44 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 04 Nov 2005 17:24:44 +0100 Subject: FC5test1 devel freeze, November 14th In-Reply-To: <1131073379.19437.294.camel@mccallum.corsepiu.local> References: <436A82AB.9070701@redhat.com> <1131073379.19437.294.camel@mccallum.corsepiu.local> Message-ID: <1131121484.14465.4.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-11-04 at 04:02 +0100, Ralf Corsepius wrote: > On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote: > > If you are involved in the development of Fedora Core as a packager, > > here is information that will be relevant to you. > > > Modular X requires FE5 Fixes > > ============================ > > The major change created by modular X is that XFree86-devel and > > xorg-x11-devel are no longer provided in the buildroot. All packages in > > both Core and Extras are now expected to have BuildRequires on the > > individual libFOO-devel packages of the newly split modular X. In order > > to ease into this, the current monolithic xorg-x11 package in rawhide > > contains many virtual provides for libFOO-devel. Modular X itself will > > hit rawhide *REAL SOON NOW*. > > Will we see corresponding "Provides: libFOO-devel = x.y.z" being added > to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward > compatibility? Now that would be so _nice_. Mike, pretty please? 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 gemi at bluewin.ch Fri Nov 4 17:14:36 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 04 Nov 2005 18:14:36 +0100 Subject: sandbox targets In-Reply-To: <1131068799.20403.63.camel@cutter> References: <1131065681.20403.57.camel@cutter> <1131068547.13629.2.camel@scriabin.tannenrauch.ch> <1131068799.20403.63.camel@cutter> Message-ID: <1131124476.7210.1.camel@scriabin.tannenrauch.ch> On Thu, 2005-11-03 at 20:46 -0500, seth vidal wrote: > > Maybe one could request a build for the HEAD of CVS, without > > tagging, then one could make changes to the spec files > > without bumbing up the release tag. > > > You can't request a build right now w/o a tag. Moreover doesn't that get > pretty odd when we think about requesting a sandbox build for the > non-development distro targets? What about the HEAD of the branch? But it's probably more complicated than I thought. Not that important though, I would just find it little less annoying to use for making testing builds without tagging. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From dcbw at redhat.com Fri Nov 4 19:01:45 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 04 Nov 2005 14:01:45 -0500 Subject: sandbox targets In-Reply-To: <1131124476.7210.1.camel@scriabin.tannenrauch.ch> References: <1131065681.20403.57.camel@cutter> <1131068547.13629.2.camel@scriabin.tannenrauch.ch> <1131068799.20403.63.camel@cutter> <1131124476.7210.1.camel@scriabin.tannenrauch.ch> Message-ID: <1131130905.10220.3.camel@dhcp83-40.boston.redhat.com> On Fri, 2005-11-04 at 18:14 +0100, G?rard Milmeister wrote: > On Thu, 2005-11-03 at 20:46 -0500, seth vidal wrote: > > > Maybe one could request a build for the HEAD of CVS, without > > > tagging, then one could make changes to the spec files > > > without bumbing up the release tag. > > > > > > You can't request a build right now w/o a tag. Moreover doesn't that get > > pretty odd when we think about requesting a sandbox build for the > > non-development distro targets? > What about the HEAD of the branch? But it's probably more complicated > than I thought. Not that important though, I would just find it little > less annoying to use for making testing builds without tagging. On the flip side, I think that just allowing HEAD builds would more or less encourage people to just dump builds into the buildsystem. If we -require- you to tag the build before submitting it, I would guess that little barrier would make people think twice before submitting it. We need to strike a balance here between people who might use the build system as a personal development machine (if they don't have PPC for example) and those people who do actually have a reasonable expectation that the package will build for them. A small little barrier like requiring a tag, while not much, is a psychological handbrake on dumping stuff into the buildsystem. Dan From mharris at redhat.com Fri Nov 4 23:47:37 2005 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 04 Nov 2005 18:47:37 -0500 Subject: FC5test1 devel freeze, November 14th In-Reply-To: <1131073379.19437.294.camel@mccallum.corsepiu.local> References: <436A82AB.9070701@redhat.com> <1131073379.19437.294.camel@mccallum.corsepiu.local> Message-ID: <436BF319.4050709@redhat.com> Ralf Corsepius wrote: > On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote: > >>If you are involved in the development of Fedora Core as a packager, >>here is information that will be relevant to you. > > >>Modular X requires FE5 Fixes >>============================ >>The major change created by modular X is that XFree86-devel and >>xorg-x11-devel are no longer provided in the buildroot. All packages in >>both Core and Extras are now expected to have BuildRequires on the >>individual libFOO-devel packages of the newly split modular X. In order >>to ease into this, the current monolithic xorg-x11 package in rawhide >>contains many virtual provides for libFOO-devel. Modular X itself will >>hit rawhide *REAL SOON NOW*. > > > Will we see corresponding "Provides: libFOO-devel = x.y.z" being added > to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward > compatibility? That's not a bad idea. If somebody files separate bug reports against FC3 and FC4, I'll try to make sure the next Fedora updates have these virtual provides present. That will make things even easier for 3rd party repos to share spec files between various distro releases. Not sure when we'll make the next FC Xorg updates though, we're pretty tied down right now. ;) But there will be updates at some point. Thanks for the suggestion. From tgl at redhat.com Sat Nov 5 07:56:16 2005 From: tgl at redhat.com (Tom Lane) Date: Sat, 05 Nov 2005 02:56:16 -0500 Subject: sandbox targets In-Reply-To: <1131130905.10220.3.camel@dhcp83-40.boston.redhat.com> References: <1131065681.20403.57.camel@cutter> <1131068547.13629.2.camel@scriabin.tannenrauch.ch> <1131068799.20403.63.camel@cutter> <1131124476.7210.1.camel@scriabin.tannenrauch.ch> <1131130905.10220.3.camel@dhcp83-40.boston.redhat.com> Message-ID: <21442.1131177376@sss.pgh.pa.us> Dan Williams writes: > We need to strike a balance here between people who might use the build > system as a personal development machine (if they don't have PPC for > example) and those people who do actually have a reasonable expectation > that the package will build for them. > A small little barrier like requiring a tag, while not much, is a > psychological handbrake on dumping stuff into the buildsystem. Certainly it's reasonable to expect people to have successfully built a package locally before they dump it into the build system. But you can't expect them to have built it on all N architectures beforehand --- so there is *always* some question in the mind when launching a build. (And that's supposing that the build system doesn't impose any hazards of its own ... which isn't the case for Red Hat's internal beehive system at least :-() Not sure about the best tradeoffs here. One thing I think ought to be more easily possible is to launch a build on a "scratch" basis, and then transfer the result into the "real results" arena only after you've checked it out. regards, tom lane From sundaram at redhat.com Mon Nov 7 03:09:45 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 07 Nov 2005 08:39:45 +0530 Subject: [Fwd: IMPORTANT: xinitrc soon to be obsolete and replaced by xorg-x11-xinit and xorg-x11-xdm] Message-ID: <436EC579.2070802@redhat.com> -------------- next part -------------- An embedded message was scrubbed... From: "Mike A. Harris" Subject: IMPORTANT: xinitrc soon to be obsolete and replaced by xorg-x11-xinit and xorg-x11-xdm Date: Thu, 03 Nov 2005 15:37:20 -0500 Size: 4135 URL: From sundaram at redhat.com Mon Nov 7 03:11:18 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 07 Nov 2005 08:41:18 +0530 Subject: [Fwd: IMPORTANT: font package owners - modular X required changes] Message-ID: <436EC5D6.6060604@redhat.com> -------------- next part -------------- An embedded message was scrubbed... From: "Mike A. Harris" Subject: IMPORTANT: font package owners - modular X required changes Date: Sat, 05 Nov 2005 08:08:12 -0500 Size: 5889 URL: From sundaram at redhat.com Mon Nov 7 03:13:06 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 07 Nov 2005 08:43:06 +0530 Subject: [Fwd: Where should the modular X11R7 fonts get installed to?] Message-ID: <436EC642.70407@redhat.com> -------------- next part -------------- An embedded message was scrubbed... From: "Mike A. Harris" Subject: Where should the modular X11R7 fonts get installed to? Date: Sun, 06 Nov 2005 10:13:06 -0500 Size: 4494 URL: From tmraz at redhat.com Tue Nov 8 12:06:04 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 08 Nov 2005 13:06:04 +0100 Subject: Are you ready for another rawhide breakage? Message-ID: <1131451564.3037.12.camel@perun.redhat.usu> Hi all, as we are approaching the FC-5 test 1 devel freeze I'd like to upgrade one more package which involves rebuild of many dependent packages. This package is openssl (0.9.8a) and as it is a version change there might be even needed some minor patches to package sources. I'll try to rebuild all dependent Core packages whenever possible but if you are an owner of dependent package in devel Extras, please rebuild as soon as the new openssl package is available in FC5 devel. There won't be any openssl097f compat package as the openssl-0.9.7f was released only in FC4 and so it probably wasn't much used by ISVs in their build environments. -- Tomas Mraz From tmraz at redhat.com Tue Nov 8 13:01:34 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 08 Nov 2005 14:01:34 +0100 Subject: Are you ready for another rawhide breakage? In-Reply-To: <1131451564.3037.12.camel@perun.redhat.usu> References: <1131451564.3037.12.camel@perun.redhat.usu> Message-ID: <1131454894.3037.18.camel@perun.redhat.usu> On Tue, 2005-11-08 at 13:06 +0100, Tomas Mraz wrote: > Hi all, > > as we are approaching the FC-5 test 1 devel freeze I'd like to upgrade > one more package which involves rebuild of many dependent packages. This > package is openssl (0.9.8a) and as it is a version change there might be > even needed some minor patches to package sources. I'll try to rebuild > all dependent Core packages whenever possible but if you are an owner of > dependent package in devel Extras, please rebuild as soon as the new > openssl package is available in FC5 devel. List of extras packages to rebuild: amarok-1.3.5-1.fc5.src.rpm apcupsd-3.10.18-4.fc5.src.rpm apt-0.5.15cnc7-2.src.rpm bazaar-1.4.2-2.fc5.src.rpm bzflag-2.0.2-4.src.rpm centericq-4.21.0-1.fc5.src.rpm cfengine-2.1.16-2.fc5.src.rpm cone-0.65-1.fc5.src.rpm ctrlproxy-2.6.2-4.fc5.src.rpm cyrus-imapd-2.2.12-6.fc4.src.rpm d4x-2.5.5-1.fc5.src.rpm darcs-1.0.3-2.fc5.src.rpm dclib-0.3.7-3.fc5.src.rpm diradmin-1.6.0-1.fc5.src.rpm elmo-1.2.0-4.src.rpm erlang-R10B-6.4.fc5.src.rpm esmtp-0.5.1-7.fc5.src.rpm exim-4.54-1.fc5.src.rpm flow-tools-0.68-4.fc5.src.rpm fwbuilder-2.0.6-3.src.rpm ghasher-1.2.0-6.fc5.src.rpm git-core-0.99.8f-1.fc5.src.rpm grip-3.2.0-8.fc5.src.rpm gtorrentviewer-0.2b-6.fc5.src.rpm hdf5-1.6.4-4.fc5.src.rpm http_ping-20050629-1.fc5.src.rpm irssi-0.8.9-7.src.rpm kannel-1.4.0-5.src.rpm kasablanca-0.4.0.2-2.fc5.src.rpm koffice-1.4.2-1.fc5.src.rpm kphone-4.2-2.fc5.src.rpm libesmtp-1.0.3r1-4.fc5.src.rpm libetpan-0.39.1-1.fc5.src.rpm libfwbuilder-2.0.6-3.src.rpm lighttpd-1.4.6-1.fc5.src.rpm mail-notification-2.0-6.fc5.src.rpm nail-11.25-4.fc5.src.rpm opensc-0.9.6-2.src.rpm openslp-1.2.1-2.fc5.src.rpm openvpn-2.1-0.1.beta6.fc5.src.rpm pam_mount-0.9.25-4.src.rpm pam_ssh-1.91-9.fc5.src.rpm perl-Net-SSLeay-1.26-2.src.rpm pgadmin3-1.0.2-5.src.rpm pl-5.4.6-9.src.rpm plt-scheme-299.200-10.fc5.src.rpm proftpd-1.2.10-6.fc5.src.rpm pure-ftpd-1.0.20-3.fc5.src.rpm qca-tls-1.0-4.src.rpm scribus-1.2.1-5.src.rpm sword-1.5.8-4.fc5.src.rpm sylpheed-2.0.3-1.src.rpm sylpheed-claws-1.9.15-1.fc5.src.rpm tla-1.3.1-4.fix.1.src.rpm tripwire-2.3.1-22.src.rpm up-imapproxy-1.2.4-4.fc5.src.rpm uw-imap-2004g-1.fc5.src.rpm valknut-0.3.7-4.fc5.src.rpm x3270-3.3.4-6.fc5.src.rpm xca-0.5.1-3.fc4.src.rpm xfprint-4.2.2-1.fc4.src.rpm xsupplicant-1.2.1-5.fc5.src.rpm List of core packages to rebuild (I'll take care of them if they rebuild cleanly.): authd-1.4.3-5.devel.src.rpm bind-9.3.1-20.src.rpm cadaver-0.22.2-2.src.rpm crypto-utils-2.2-7.src.rpm cups-1.1.23-24.src.rpm curl-7.15.0-1.src.rpm cyrus-sasl-2.1.21-5.src.rpm desktop-printing-0.19-2.src.rpm distcache-1.4.5-11.src.rpm dovecot-0.99.14-8.fc5.src.rpm elinks-0.10.6-1.src.rpm ethereal-0.10.13-3.src.rpm evolution-connector-2.4.1-1.src.rpm fetchmail-6.2.5.2-1.src.rpm freeradius-1.0.4-3.src.rpm gftp-2.0.18-2.src.rpm ghostscript-8.15.1-1.src.rpm gimp-print-4.2.7-12.src.rpm gkrellm-2.2.7-3.src.rpm gnome-vfs2-2.12.1.1-4.src.rpm gwenhywfar-1.7.2-2.src.rpm hplip-0.9.6-4.src.rpm httpd-2.0.54-15.src.rpm ipsec-tools-0.6.1-1.src.rpm jpilot-0.99.8-1.src.rpm kdebase-3.4.92-1.src.rpm kdelibs-3.4.92-2.src.rpm kdenetwork-3.4.92-1.src.rpm kdesdk-3.4.92-1.src.rpm kdeutils-3.4.92-3.src.rpm libc-client-2002e-11.src.rpm libgnomecups-0.2.2-1.src.rpm libgnomeprint22-2.12.1-2.src.rpm libwvstreams-3.75.0-5.src.rpm lynx-2.8.5-24.src.rpm m2crypto-0.15-1.src.rpm mod_authz_ldap-0.26-3.src.rpm mutt-1.4.2.1-5.src.rpm MySQL-python-1.2.0-2.src.rpm neon-0.24.7-8.src.rpm netatalk-2.0.3-3.src.rpm net-snmp-5.2.2-0.rc3.1.src.rpm nmap-3.93-1.src.rpm ntp-4.2.0.a.20050816-9.src.rpm nut-2.0.2-3.src.rpm openhpi-2.0.3-3.src.rpm OpenIPMI-1.4.14-11.src.rpm openldap-2.2.29-2.src.rpm openssh-4.2p1-5.src.rpm openssl-0.9.7f-11.src.rpm pam_ccreds-1-7.src.rpm perl-Crypt-SSLeay-0.51-8.src.rpm perl-DBD-MySQL-3.0002-1.src.rpm perl-RPM2-0.66-9.src.rpm php-5.0.5-4.src.rpm postfix-2.2.5-1.src.rpm pyOpenSSL-0.6-1.p24.6.src.rpm python-2.4.1-14.src.rpm python-ldap-2.0.6-4.src.rpm rdesktop-1.4.1-1.fc5.src.rpm rpm-4.4.2-6.src.rpm ruby-1.8.4-0.2.preview1.src.rpm samba-3.0.20-2.src.rpm sendmail-8.13.5-1.src.rpm slrn-0.9.8.1-5.src.rpm spamassassin-3.1.0-1.fc5.src.rpm squid-2.5.STABLE11-6.src.rpm stunnel-4.14-1.src.rpm subversion-1.2.3-3.src.rpm tcpdump-3.9.3-3.src.rpm tn5250-0.16.5-6.src.rpm tog-pegasus-2.5-2.src.rpm vorbis-tools-1.0.1-6.src.rpm vsftpd-2.0.3-11.src.rpm w3m-0.5.1-10.src.rpm wget-1.10.2-2.src.rpm xchat-2.4.5-1.src.rpm xmlsec1-1.2.9-1.src.rpm -- Tomas Mraz From jorton at redhat.com Tue Nov 8 13:22:51 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 8 Nov 2005 13:22:51 +0000 Subject: Are you ready for another rawhide breakage? In-Reply-To: <1131451564.3037.12.camel@perun.redhat.usu> References: <1131451564.3037.12.camel@perun.redhat.usu> Message-ID: <20051108132251.GA25672@redhat.com> On Tue, Nov 08, 2005 at 01:06:04PM +0100, Tomas Mraz wrote: > as we are approaching the FC-5 test 1 devel freeze I'd like to upgrade > one more package which involves rebuild of many dependent packages. This > package is openssl (0.9.8a) and as it is a version change there might be > even needed some minor patches to package sources. I'll try to rebuild > all dependent Core packages whenever possible but if you are an owner of > dependent package in devel Extras, please rebuild as soon as the new > openssl package is available in FC5 devel. > > There won't be any openssl097f compat package as the openssl-0.9.7f was > released only in FC4 and so it probably wasn't much used by ISVs in > their build environments. Sunds good. I'm away for a couple of weeks starting tomorrow so if any of my packages fail to rebuild against 0.9.8 can you take care of that? I think they should all build albeit with warnings because of the constness API changes. joe From tmraz at redhat.com Tue Nov 8 13:56:36 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 08 Nov 2005 14:56:36 +0100 Subject: Are you ready for another rawhide breakage? In-Reply-To: <20051108131923.GA3043@dudweiler.stuttgart.redhat.com> References: <1131451564.3037.12.camel@perun.redhat.usu> <1131454894.3037.18.camel@perun.redhat.usu> <20051108131923.GA3043@dudweiler.stuttgart.redhat.com> Message-ID: <1131458196.3037.22.camel@perun.redhat.usu> On Tue, 2005-11-08 at 14:19 +0100, Florian La Roche wrote: > Hello Tom, > > seems the list is pretty long. Maybe a compat lib would make > sense then? The packages should be rebuilt anyway so the compat lib would be helpful only for short time. I don't think it's worth it. Maybe we could add the compat package only to Extras to ease the transition of Extras packages? -- Tomas Mraz From tgl at redhat.com Tue Nov 8 14:10:45 2005 From: tgl at redhat.com (Tom Lane) Date: Tue, 08 Nov 2005 09:10:45 -0500 Subject: Are you ready for another rawhide breakage? In-Reply-To: <1131454894.3037.18.camel@perun.redhat.usu> References: <1131451564.3037.12.camel@perun.redhat.usu> <1131454894.3037.18.camel@perun.redhat.usu> Message-ID: <4940.1131459045@sss.pgh.pa.us> Tomas Mraz writes: > List of core packages to rebuild (I'll take care of them if they rebuild > cleanly.): Not sure how you derived this list, but it's badly incomplete. Among my packages, I know offhand that postgresql and mysql both use openssl, and neither is listed ... regards, tom lane From tmraz at redhat.com Tue Nov 8 14:38:22 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 08 Nov 2005 15:38:22 +0100 Subject: Are you ready for another rawhide breakage? In-Reply-To: <4940.1131459045@sss.pgh.pa.us> References: <1131451564.3037.12.camel@perun.redhat.usu> <1131454894.3037.18.camel@perun.redhat.usu> <4940.1131459045@sss.pgh.pa.us> Message-ID: <1131460702.3037.30.camel@perun.redhat.usu> On Tue, 2005-11-08 at 09:10 -0500, Tom Lane wrote: > Tomas Mraz writes: > > List of core packages to rebuild (I'll take care of them if they rebuild > > cleanly.): > > Not sure how you derived this list, but it's badly incomplete. > Among my packages, I know offhand that postgresql and mysql both use > openssl, and neither is listed ... Using repoquery, but I've probably made some mistake on its command line. Here is the "should be correct" list. It isn't so much different from the previous one: authd-1.4.3-5.devel.src.rpm bind-9.3.1-20.src.rpm cadaver-0.22.2-2.src.rpm ckermit-8.0.211-3.src.rpm crypto-utils-2.2-7.src.rpm cups-1.1.23-24.src.rpm curl-7.15.0-1.src.rpm cyrus-sasl-2.1.21-5.src.rpm desktop-printing-0.19-2.src.rpm dhcpv6-0.10-14.src.rpm distcache-1.4.5-11.src.rpm dovecot-0.99.14-8.fc5.src.rpm elinks-0.10.6-1.src.rpm ethereal-0.10.13-3.src.rpm evolution-connector-2.4.1-1.src.rpm fetchmail-6.2.5.2-1.src.rpm freeradius-1.0.4-3.src.rpm gftp-2.0.18-2.src.rpm ghostscript-8.15.1-1.src.rpm gimp-print-4.2.7-12.src.rpm gkrellm-2.2.7-3.src.rpm gnome-vfs2-2.12.1.1-4.src.rpm gwenhywfar-1.7.2-2.src.rpm hplip-0.9.6-5.src.rpm httpd-2.0.54-15.src.rpm ipsec-tools-0.6.1-1.src.rpm jpilot-0.99.8-1.src.rpm kdebase-3.4.92-1.src.rpm kdelibs-3.4.92-2.src.rpm kdenetwork-3.4.92-1.src.rpm kdesdk-3.4.92-1.src.rpm kdeutils-3.4.92-3.src.rpm libc-client-2002e-11.src.rpm libgnomecups-0.2.2-1.src.rpm libgnomeprint22-2.12.1-2.src.rpm libwvstreams-3.75.0-5.src.rpm lynx-2.8.5-24.src.rpm m2crypto-0.15-1.src.rpm mod_authz_ldap-0.26-3.src.rpm mutt-1.4.2.1-5.src.rpm mysql-4.1.14-1.src.rpm MySQL-python-1.2.0-2.src.rpm neon-0.24.7-8.src.rpm netatalk-2.0.3-3.src.rpm net-snmp-5.2.2-0.rc4.1.src.rpm nmap-3.93-1.src.rpm ntp-4.2.0.a.20050816-9.src.rpm nut-2.0.2-3.src.rpm openhpi-2.0.3-4.src.rpm OpenIPMI-1.4.14-11.src.rpm openldap-2.2.29-2.src.rpm openssh-4.2p1-5.src.rpm pam_ccreds-1-7.src.rpm perl-Crypt-SSLeay-0.51-8.src.rpm perl-DBD-MySQL-3.0002-1.src.rpm perl-RPM2-0.66-9.src.rpm php-5.0.5-5.src.rpm postfix-2.2.5-1.src.rpm postgresql-8.1.0-1.src.rpm pyOpenSSL-0.6-1.p24.6.src.rpm python-2.4.1-14.src.rpm python-ldap-2.0.6-4.src.rpm rdesktop-1.4.1-1.fc5.src.rpm rpm-4.4.2-6.src.rpm ruby-1.8.4-0.2.preview1.src.rpm samba-3.0.20-2.src.rpm sendmail-8.13.5-1.src.rpm slrn-0.9.8.1-5.src.rpm spamassassin-3.1.0-1.fc5.src.rpm squid-2.5.STABLE11-6.src.rpm stunnel-4.14-1.src.rpm subversion-1.2.3-3.src.rpm tcpdump-3.9.3-3.src.rpm tn5250-0.16.5-6.src.rpm tog-pegasus-2.5-2.src.rpm vorbis-tools-1.0.1-6.src.rpm vsftpd-2.0.3-11.src.rpm w3m-0.5.1-10.src.rpm wget-1.10.2-2.src.rpm xchat-2.4.5-1.src.rpm xmlsec1-1.2.9-1.src.rpm -- Tomas Mraz From alexl at redhat.com Wed Nov 9 13:45:01 2005 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 09 Nov 2005 14:45:01 +0100 Subject: Moving packages from extras to core In-Reply-To: <1130832134.27894.2.camel@rydia.hardsun.net> References: <1129912233.13150.43.camel@greebo> <1130832134.27894.2.camel@rydia.hardsun.net> Message-ID: <1131543902.3231.82.camel@greebo> On Tue, 2005-11-01 at 00:02 -0800, Aaron Kurtz wrote: > On Fri, 2005-10-21 at 18:30 +0200, Alexander Larsson wrote: > > > Also, how will this work wrt maintainership of the package? I'm fine > > with owning this package inside redhat, but I don't want to steal it > > from the current extras maintainer (cc:ed). I just needed it in core due > > to the Avahi dependency. > > As the maintainer of libdaemon, if you'd like to handle it in Extras for > FC3 and FC4, feel free. I took it over only because the prior > maintainer's address was bouncing and I was attempting to get another > package into Extras that needed an updated version. Jason Vas Dias has now taken over this, with the avahi package. You guys should figure out how to handle this. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an otherworldly zombie card sharp on the hunt for the last specimen of a great and near-mythical creature. She's a sharp-shooting communist stripper with someone else's memories. They fight crime! From alexl at redhat.com Wed Nov 9 13:54:59 2005 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 09 Nov 2005 14:54:59 +0100 Subject: Moving nautilus-sendto to extras Message-ID: <1131544499.3231.93.camel@greebo> We (the Red Hat desktop group) think it would make sense to ship nautilus-sendto in Core. Its a small app that integrates already existing features in the desktop in a nice way. Plus it avoids a regression since the bluetooth-specific sendto nautilus menu item was removed from gnome-bluetooth. However, nautilus-sendto already exists in extras, so this is slightly complicated. I've CC:ed the current extras maintainer. Is this move ok with you? Also, before I noticed the package in extras i made a quick package myself, and i did it a bit differently. I put the gaim plugin in the main package, as it actually has no extra dependencies and isn't listed in the UI unless you actually use gaim. Instead I put the evolution plugin in a separate package (although that was perhaps unnecessary). What is your opinion on this Paul? Also, I'm not sure why you added gnome-desktop-devel to the build-requirements. That library is not actually used by nautilus-sendto. "libglade2-devel, libgnomeui-devel" would be a better requirement. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an ungodly ninja waffle chef with no name. She's a cynical insomniac opera singer prone to fits of savage, blood-crazed rage. They fight crime! From jamatos at fc.up.pt Wed Nov 9 15:08:12 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 9 Nov 2005 15:08:12 +0000 Subject: Moving packages from extras to core In-Reply-To: <1131543902.3231.82.camel@greebo> References: <1129912233.13150.43.camel@greebo> <1130832134.27894.2.camel@rydia.hardsun.net> <1131543902.3231.82.camel@greebo> Message-ID: <200511091508.12171.jamatos@fc.up.pt> On Wednesday 09 November 2005 13:45, Alexander Larsson wrote: > Jason Vas Dias has now taken over this, with the avahi package. You guys > should figure out how to handle this. Clearly the first picture in my mind was: 1) Both maintainer choose their best man 2) Both maintainer agree on the chosen weapon 3) The duel will be at thirty feet and Tom Spot is the referee 4) The one who survives maintains both packages But I guess that it was not your intention in first place. Oh well, too few Guinness or too much mushrooms here in Dublin. ;-) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > ?Alexander Larsson ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Red Hat, Inc -- Jos? Ab?lio From tcallawa at redhat.com Wed Nov 9 15:13:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Nov 2005 09:13:50 -0600 Subject: Moving packages from extras to core In-Reply-To: <200511091508.12171.jamatos@fc.up.pt> References: <1129912233.13150.43.camel@greebo> <1130832134.27894.2.camel@rydia.hardsun.net> <1131543902.3231.82.camel@greebo> <200511091508.12171.jamatos@fc.up.pt> Message-ID: <1131549230.2213.45.camel@localhost.localdomain> On Wed, 2005-11-09 at 15:08 +0000, Jose' Matos wrote: > On Wednesday 09 November 2005 13:45, Alexander Larsson wrote: > > Jason Vas Dias has now taken over this, with the avahi package. You guys > > should figure out how to handle this. > > Clearly the first picture in my mind was: > > 1) Both maintainer choose their best man > 2) Both maintainer agree on the chosen weapon > 3) The duel will be at thirty feet and Tom Spot is the referee > 4) The one who survives maintains both packages Gentlemen, choose your toolkits and meet behind the old Digital facility at high noon. TWO MAN ENTER, ONE MAN LEAVE! TWO MAN ENTER, ONE MAN LEAVE! ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From alexl at redhat.com Wed Nov 9 14:33:25 2005 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 09 Nov 2005 15:33:25 +0100 Subject: fedora-mainatiners CC munging? In-Reply-To: <1131544499.3231.93.camel@greebo> References: <1131544499.3231.93.camel@greebo> Message-ID: <1131546805.3231.102.camel@greebo> On Wed, 2005-11-09 at 14:54 +0100, Alexander Larsson wrote: > However, nautilus-sendto already exists in extras, so this is slightly > complicated. I've CC:ed the current extras maintainer. Is this move ok > with you? The message in my sent folder has: Cc: Paul W. Frields However, the message on the list doesn't have any CC line. Whats up with this? Is the mail server eating the CC? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick crooked dwarf in drag. She's a bloodthirsty kleptomaniac barmaid operating on the wrong side of the law. They fight crime! From skvidal at phy.duke.edu Wed Nov 9 15:35:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 09 Nov 2005 10:35:25 -0500 Subject: fedora-mainatiners CC munging? In-Reply-To: <1131546805.3231.102.camel@greebo> References: <1131544499.3231.93.camel@greebo> <1131546805.3231.102.camel@greebo> Message-ID: <1131550525.5745.2.camel@cutter> On Wed, 2005-11-09 at 15:33 +0100, Alexander Larsson wrote: > On Wed, 2005-11-09 at 14:54 +0100, Alexander Larsson wrote: > > > However, nautilus-sendto already exists in extras, so this is slightly > > complicated. I've CC:ed the current extras maintainer. Is this move ok > > with you? > > The message in my sent folder has: > Cc: Paul W. Frields > > However, the message on the list doesn't have any CC line. Whats up with > this? Is the mail server eating the CC? > The list has reply-to set. -sv From fedora at camperquake.de Wed Nov 9 15:40:20 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 9 Nov 2005 16:40:20 +0100 Subject: fedora-mainatiners CC munging? In-Reply-To: <1131550525.5745.2.camel@cutter> References: <1131544499.3231.93.camel@greebo> <1131546805.3231.102.camel@greebo> <1131550525.5745.2.camel@cutter> Message-ID: <20051109154020.GB18518@ryoko.camperquake.de> On Wed, Nov 09, 2005 at 10:35:25AM -0500, seth vidal wrote: > > However, the message on the list doesn't have any CC line. Whats up with > > this? Is the mail server eating the CC? > > > > The list has reply-to set. How exactly does that justify eating the Cc: header? From dmalcolm at redhat.com Wed Nov 9 15:41:49 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 09 Nov 2005 10:41:49 -0500 Subject: Moving packages from extras to core In-Reply-To: <1131549230.2213.45.camel@localhost.localdomain> References: <1129912233.13150.43.camel@greebo> <1130832134.27894.2.camel@rydia.hardsun.net> <1131543902.3231.82.camel@greebo> <200511091508.12171.jamatos@fc.up.pt> <1131549230.2213.45.camel@localhost.localdomain> Message-ID: <1131550910.2801.7.camel@cassandra.boston.redhat.com> On Wed, 2005-11-09 at 09:13 -0600, Tom 'spot' Callaway wrote: > On Wed, 2005-11-09 at 15:08 +0000, Jose' Matos wrote: > > On Wednesday 09 November 2005 13:45, Alexander Larsson wrote: > > > Jason Vas Dias has now taken over this, with the avahi package. You guys > > > should figure out how to handle this. > > > > Clearly the first picture in my mind was: > > > > 1) Both maintainer choose their best man > > 2) Both maintainer agree on the chosen weapon > > 3) The duel will be at thirty feet and Tom Spot is the referee > > 4) The one who survives maintains both packages > > Gentlemen, choose your toolkits and meet behind the old Digital facility > at high noon. TWO MAN ENTER, ONE MAN LEAVE! TWO MAN ENTER, ONE MAN > LEAVE! > The first rule of Package Club is http://fedoraproject.org/wiki/PackagingGuidelines The second rule of Package Club is http://fedoraproject.org/wiki/PackagingGuidelines (sorry, couldn't resist) :-P From dwmw2 at infradead.org Wed Nov 9 15:43:55 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 Nov 2005 15:43:55 +0000 Subject: fedora-mainatiners CC munging? In-Reply-To: <20051109154020.GB18518@ryoko.camperquake.de> References: <1131544499.3231.93.camel@greebo> <1131546805.3231.102.camel@greebo> <1131550525.5745.2.camel@cutter> <20051109154020.GB18518@ryoko.camperquake.de> Message-ID: <1131551035.27347.148.camel@baythorne.infradead.org> On Wed, 2005-11-09 at 16:40 +0100, Ralf Ertzinger wrote: > How exactly does that justify eating the Cc: header? Two wrongs make a right? -- dwmw2 From tcallawa at redhat.com Wed Nov 9 15:48:15 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 09 Nov 2005 09:48:15 -0600 Subject: Moving packages from extras to core In-Reply-To: <1131550910.2801.7.camel@cassandra.boston.redhat.com> References: <1129912233.13150.43.camel@greebo> <1130832134.27894.2.camel@rydia.hardsun.net> <1131543902.3231.82.camel@greebo> <200511091508.12171.jamatos@fc.up.pt> <1131549230.2213.45.camel@localhost.localdomain> <1131550910.2801.7.camel@cassandra.boston.redhat.com> Message-ID: <1131551295.2213.52.camel@localhost.localdomain> On Wed, 2005-11-09 at 10:41 -0500, David Malcolm wrote: > On Wed, 2005-11-09 at 09:13 -0600, Tom 'spot' Callaway wrote: > > On Wed, 2005-11-09 at 15:08 +0000, Jose' Matos wrote: > > > On Wednesday 09 November 2005 13:45, Alexander Larsson wrote: > > > > Jason Vas Dias has now taken over this, with the avahi package. You guys > > > > should figure out how to handle this. > > > > > > Clearly the first picture in my mind was: > > > > > > 1) Both maintainer choose their best man > > > 2) Both maintainer agree on the chosen weapon > > > 3) The duel will be at thirty feet and Tom Spot is the referee > > > 4) The one who survives maintains both packages > > > > Gentlemen, choose your toolkits and meet behind the old Digital facility > > at high noon. TWO MAN ENTER, ONE MAN LEAVE! TWO MAN ENTER, ONE MAN > > LEAVE! > > > The first rule of Package Club is > http://fedoraproject.org/wiki/PackagingGuidelines > > The second rule of Package Club is > http://fedoraproject.org/wiki/PackagingGuidelines I need that on a T-shirt with the Fedora logo in a bar of soap on the front. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From tgl at redhat.com Wed Nov 9 18:39:49 2005 From: tgl at redhat.com (Tom Lane) Date: Wed, 09 Nov 2005 13:39:49 -0500 Subject: Are you ready for another rawhide breakage? In-Reply-To: <1131451564.3037.12.camel@perun.redhat.usu> References: <1131451564.3037.12.camel@perun.redhat.usu> Message-ID: <18015.1131561589@sss.pgh.pa.us> Tomas Mraz writes: > as we are approaching the FC-5 test 1 devel freeze I'd like to upgrade > one more package which involves rebuild of many dependent packages. This > package is openssl (0.9.8a) and as it is a version change there might be > even needed some minor patches to package sources. OK, so I got the "broken deps" warning overnight and did a rebuild just now. Doesn't seem to have helped any though: [tgl at porkchop i386]$ rpm -qp postgresql-libs-8.1.0-1.i386.rpm --requires | grep ssl libssl.so.5 [tgl at porkchop postgresql]$ cd ../../8.1.0-2/i386 [tgl at porkchop i386]$ rpm -qp postgresql-libs-8.1.0-2.i386.rpm --requires | grep ssl libssl.so.5 Anyone care to explain why the build system is nagging us about broken deps when the old openssl is still in the buildroots? And what are the nag-ees supposed to do about it? regards, tom lane From tmraz at redhat.com Wed Nov 9 19:02:54 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 09 Nov 2005 20:02:54 +0100 Subject: Are you ready for another rawhide breakage? In-Reply-To: <18015.1131561589@sss.pgh.pa.us> References: <1131451564.3037.12.camel@perun.redhat.usu> <18015.1131561589@sss.pgh.pa.us> Message-ID: <1131562974.3035.4.camel@perun.redhat.usu> On Wed, 2005-11-09 at 13:39 -0500, Tom Lane wrote: > Tomas Mraz writes: > > as we are approaching the FC-5 test 1 devel freeze I'd like to upgrade > > one more package which involves rebuild of many dependent packages. This > > package is openssl (0.9.8a) and as it is a version change there might be > > even needed some minor patches to package sources. > > OK, so I got the "broken deps" warning overnight and did a rebuild just now. > Doesn't seem to have helped any though: > > [tgl at porkchop i386]$ rpm -qp postgresql-libs-8.1.0-1.i386.rpm --requires | grep ssl > libssl.so.5 > [tgl at porkchop postgresql]$ cd ../../8.1.0-2/i386 > [tgl at porkchop i386]$ rpm -qp postgresql-libs-8.1.0-2.i386.rpm --requires | grep ssl > libssl.so.5 > > Anyone care to explain why the build system is nagging us about broken > deps when the old openssl is still in the buildroots? And what are > the nag-ees supposed to do about it? This is really strange every other package I've just rebuilt is linked correctly to libssl.so.6. The old openssl had to be put there because it was required for rpm. Otherwise rpm would be broken and thus buildroots too. I've now moved the openssl097f package out of the dist-fc5-build we will see if it helps or not. -- Tomas Mraz From tgl at redhat.com Wed Nov 9 21:58:25 2005 From: tgl at redhat.com (Tom Lane) Date: Wed, 09 Nov 2005 16:58:25 -0500 Subject: Still more rawhide breakage: mysql 4.1 -> mysql 5.0 Message-ID: <19793.1131573505@sss.pgh.pa.us> I am currently in process of building mysql 5.0 into HEAD. There is an ABI change involved here --- libmysqlclient.so.14 is replaced by libmysqlclient.so.15. I have already created a "mysqlclient14" compatibility package to continue to provide the old client library, but it'd be a good idea to rebuild packages that depend on the mysql library soon. I'm willing to launch the rebuilds for any core packages that need it; let me know if you want this, or don't want it, for your packages. I'm not currently aware of any source-code changes that would be needed to migrate to using the .15 library, but if you run into any such problems I'd appreciate hearing about them. If for some reason you want to stick to using the 4.1 client library, you'll need some specfile changes to pick up the 4.1 headers and library files from mysqlclient14 in your future builds --- basically, BuildRequires: mysqlclient14-devel and then add -I %{_includedir}/mysql4/mysql -L %{_libdir}/mysql4/mysql regards, tom lane From sundaram at redhat.com Thu Nov 10 07:04:25 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 10 Nov 2005 12:34:25 +0530 Subject: [Fwd: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist very soon.] Message-ID: <4372F0F9.2080409@redhat.com> -------------- next part -------------- An embedded message was scrubbed... From: "Mike A. Harris" Subject: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist very soon. Date: Wed, 09 Nov 2005 20:30:04 -0500 Size: 4407 URL: From ville.skytta at iki.fi Thu Nov 10 07:20:36 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 10 Nov 2005 09:20:36 +0200 Subject: [Fwd: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist very soon.] In-Reply-To: <4372F0F9.2080409@redhat.com> References: <4372F0F9.2080409@redhat.com> Message-ID: <1131607236.28527.107.camel@localhost.localdomain> On Thu, 2005-11-10 at 12:34 +0530, Rahul Sundaram wrote: > email message attachment (ATTENTION: XFree86-devel and xorg-x11-devel > will no longer exist very soon.) It would be useful to have the contents of all these new *-devel packages somewhere online (Wiki?), ie. which libs and especially headers are in which -devel package etc. From sundaram at redhat.com Thu Nov 10 07:38:59 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 10 Nov 2005 13:08:59 +0530 Subject: [Fwd: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist very soon.] In-Reply-To: <1131607236.28527.107.camel@localhost.localdomain> References: <4372F0F9.2080409@redhat.com> <1131607236.28527.107.camel@localhost.localdomain> Message-ID: <4372F913.5060606@redhat.com> Ville Skytt? wrote: >On Thu, 2005-11-10 at 12:34 +0530, Rahul Sundaram wrote: > > >>email message attachment (ATTENTION: XFree86-devel and xorg-x11-devel >>will no longer exist very soon.) >> >> > >It would be useful to have the contents of all these new *-devel >packages somewhere online (Wiki?), ie. which libs and especially headers >are in which -devel package etc. > Mike Harris has this wiki page http://mharris.ca/xorg-modular/xorg-modularization.html I have imported this into the Fedora project wiki. http://fedoraproject.org/wiki/Xorg/Modularization regards Rahul From petersen at redhat.com Thu Nov 10 08:58:05 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 10 Nov 2005 17:58:05 +0900 Subject: [announce] Fedora community SCIM input survey Message-ID: <43730B9D.7090200@redhat.com> The Fedora I18N Team invites you kindly to participate in a survey to provide feedback on the SCIM (Simple Common Input Method [1]) platform for Asian language input. Packages are available in Fedora Core Development and Fedora Extras, and also for RHEL 4. The survey is available now at https://www.keysurvey.com/survey/80474/2da7/ [2] where more details can be found including package installation instructions. The survey has been translated into the following languages: Bengali, Chinese, Gujarati, Hindi, Japanese, Korean, and Punjabi. The goal of the survey is to find out what users see as the main strengths and weaknesses of SCIM to help provide focus on the most important improvements needed from the point of view of users. The survey will run until the end of Friday 25th November, UTC. We hope to receive lots of responses from a wide part of the community. A summary of the results will be made available publicly later. Thank you for your time. And special thanks to the SCIM developers and community for creating SCIM. Jens Petersen on behalf of the Fedora I18N and Translation Teams [1] http://www.scim-im.org/ [2] http://tinyurl.com/9n4qb From laroche at redhat.com Thu Nov 10 10:23:02 2005 From: laroche at redhat.com (Florian La Roche) Date: Thu, 10 Nov 2005 11:23:02 +0100 Subject: [Fwd: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist very soon.] In-Reply-To: <4372F913.5060606@redhat.com> References: <4372F0F9.2080409@redhat.com> <1131607236.28527.107.camel@localhost.localdomain> <4372F913.5060606@redhat.com> Message-ID: <20051110102302.GA2812@dudweiler.stuttgart.redhat.com> > >>email message attachment (ATTENTION: XFree86-devel and xorg-x11-devel > >>will no longer exist very soon.) Helo Mike, Wouldn't it make sense to keep xorg-x11-devel around for a bit longer? Maybe by adding a dummy package with only deps to all the new rpms that are now created would do this? regards, Florian La Roche From ville.skytta at iki.fi Thu Nov 10 15:36:09 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 10 Nov 2005 17:36:09 +0200 Subject: [Fwd: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist very soon.] In-Reply-To: <4372F913.5060606@redhat.com> References: <4372F0F9.2080409@redhat.com> <1131607236.28527.107.camel@localhost.localdomain> <4372F913.5060606@redhat.com> Message-ID: <1131636969.21951.23.camel@localhost.localdomain> On Thu, 2005-11-10 at 13:08 +0530, Rahul Sundaram wrote: > Ville Skytt? wrote: > > >On Thu, 2005-11-10 at 12:34 +0530, Rahul Sundaram wrote: > > > > > >>email message attachment (ATTENTION: XFree86-devel and xorg-x11-devel > >>will no longer exist very soon.) > >> > >> > > > >It would be useful to have the contents of all these new *-devel > >packages somewhere online (Wiki?), ie. which libs and especially headers > >are in which -devel package etc. > > > Mike Harris has this wiki page > > http://mharris.ca/xorg-modular/xorg-modularization.html Yep, I saw that, and it's great, however it doesn't quite satisfy the request above. Anyway, it just occurred to me that repoquery can be fairly easily used for that without risking accidentally borking a FC4 box which I don't want to upgrade to Rawhide right now, for example "repoquery --repoid=development -f /path/to/a/X11/header.h" (no need to have the development repo enabled by default in yum). It's pretty slow though, but doesn't probably have to be run _that_ often. From mharris at redhat.com Fri Nov 11 06:08:19 2005 From: mharris at redhat.com (Mike A. Harris) Date: Fri, 11 Nov 2005 01:08:19 -0500 Subject: [Fwd: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist very soon.] In-Reply-To: <1131607236.28527.107.camel@localhost.localdomain> References: <4372F0F9.2080409@redhat.com> <1131607236.28527.107.camel@localhost.localdomain> Message-ID: <43743553.1010007@redhat.com> Ville Skytt? wrote: > On Thu, 2005-11-10 at 12:34 +0530, Rahul Sundaram wrote: > >>email message attachment (ATTENTION: XFree86-devel and xorg-x11-devel >>will no longer exist very soon.) > > > It would be useful to have the contents of all these new *-devel > packages somewhere online (Wiki?), ie. which libs and especially headers > are in which -devel package etc. The rpms are on ftp://people.redhat.com/mharris/testing/xorg-modular-fc5 I encourage members of the Fedora community to create webpages and/or tools to query/list information of this nature. The simple method would be to use the binary rpms present there and create a custom rpmdb from it in a manner similar to the redhat-rpmdb package, then direct rpm to query for things from this custom database. In general, for converting to modular X dependencies, you can query an rpm package to find out what libraries the contents of the rpm link to by doing: rpm -qp --requires foo.i386.rpm If "libX11.so.*" shows up, then you'll want to add to the spec file: BuildRequires: libX11-devel ditto for all libraries it uses. Hope this helps. From fedora at leemhuis.info Sat Nov 12 19:54:30 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 Nov 2005 20:54:30 +0100 Subject: RFC: Fuse packages for Fedora Extras 4 / Fedora Core 5 Message-ID: <1131825270.1867.5.camel@localhost.localdomain> Hi *, Warren told me to post this to fedora-maintainers, so here I am. I prepared a fuse package for fedora-extras. From what I'm told it will probably only be in extras for FC-4 and it seem it might go straight to core devel/rawhide/FC5. Fuse ( http://fuse.sf.net ) allows normal users to mount userspace-filesystems into the file system ( for a complete list of filesystems see http://fuse.sourceforge.net/wiki/index.php/FileSystems ). The logic for this lies in a userspace program that is executed as user, but to mount it needs root permissions. Therefor one file (%{_bindir}/fusermount) is normally installed suid root (4755) by fuse. This might be a security problem and this is the problem with the current package and the reason for this mail. I posted a RFC on this to fedora-extras-list (see https://www.redhat.com/archives/fedora-extras-list/2005-October/msg01506.html and https://www.redhat.com/archives/fedora-extras-list/2005-November/msg00120.html for the whole discussion). Jeremy looked at it and is not very glad with the suid root executable. I agree with him on this issue, but fuse simply does not work without it -- not even when you add a fuse-filesystem to /etc/fstab (for a example see https://www.redhat.com/archives/fedora-extras-list/2005-November/msg00334.html ). Therefor I now use a suid root binary that is only executable for members of a special group named fuse. This still differs all other packages in core (afaik) -- cifs, smbfs, ncpfs for example ship also without suid root -- if the local admin wants to allow users to mount windows shares he has to add them to the /etc/fstab or "chmod +s /sbin/mount.cifs". This of course is reverted with every cifs-update. So guys, what to you think: Should we ship the binary suid root? Or simply ship it with the fuse group but don't suid root the binary? Or without the group (most fuse users/admins will run "chmod +s /usr/bin/fusemount" then and allow fuse for every user -- this IMHO is much more worse than the group). Or any other ideas? Example packages can be found here: http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/fuse.spec http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-2.4.1-1.src.rpm http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/fuse-sshfs.spec http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-sshfs-1.2-1.src.rpm To try it out on FC4 with all updates applied or rawhide simply do: rpmbuild --rebuild fuse-2.4.1-3.src.rpm sudo rpm -ivh rpmbuild/RPMS/i386/fuse-2.4.1-3.i386.rpm rpmbuild/RPMS/i386/fuse-libs-2.4.1-3.i386.rpm rpmbuild/RPMS/i386/fuse-devel-2.4.1-3.i386.rpm rpmbuild --rebuild fuse-sshfs-1.2-1.src.rpm rpm --rebuild rpmbuild/RPMS/i386/fuse-sshfs-1.2-2.i386.rpm sudo rpm -ivh rpmbuild/RPMS/i386/fuse-sshfs-1.2-2.i386.rpm sudo /usr/sbin/groupadd -a -G ${USER} ssh localhost mkdir fusetest sshfs foo: fusetest/ ls fusetest/ Where foo is the hostname of a machine you normally can connect to via ssh. -- Thorsten Leemhuis From fedora at leemhuis.info Sun Nov 13 07:52:32 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 Nov 2005 08:52:32 +0100 Subject: Corrected URLs for fuse packages (Was: RFC: Fuse packages for Fedora Extras 4 / Fedora Core 5) In-Reply-To: <1131825270.1867.5.camel@localhost.localdomain> References: <1131825270.1867.5.camel@localhost.localdomain> Message-ID: <1131868352.2763.4.camel@localhost.localdomain> Sorry, cut and paste error. The srpm packages I mentioned Am Samstag, den 12.11.2005, 20:54 +0100 schrieb Thorsten Leemhuis: > Example packages can be found here: > > http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/fuse.spec > http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-2.4.1-1.src.rpm > > http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/fuse-sshfs.spec > http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-sshfs-1.2-1.src.rpm are old versions. The current versions are at: http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-2.4.1-3.src.rpm http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/fuse-sshfs-1.2-2.src.rpm Sorry for the trouble. CU thl P.S.: for i in $(seq 100); do echo "thl, be more careful when doing cut an paste with urls in the future"; done -- Thorsten Leemhuis From sopwith at redhat.com Tue Nov 15 22:50:33 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 15 Nov 2005 17:50:33 -0500 (EST) Subject: Shell access to fedora.redhat.com machines Message-ID: Hi all, I've set things up so we can start to allow shell accounts on *.fedora.redhat.com (and hopefully *.fedoraproject.org, RSN), enabling more people to create and enhance Fedora infrastructure. There are now three groups in the account system - sysadmin-build (for people maintaining the build systems), sysadmin-web (for people hacking on web infrastructure) and sysadmin (for people doing general infrastructure maintenance). These shell accounts are only to be used for Fedora project-related stuff - please don't put any personal materials or services or 'stuff' in them. For fedora.redhat.com, things are set up with bastion.fedora.redhat.com as the 'bastion' host. Once you ssh into that host, you have a wide variety of systems that you can ssh to: sysadmin-web and sysadmin: app[12], proxy[1-4] sysadmin-build and sysadmin: hammer[1-3], ppc1 sysadmin: db1 and cvs-int You can login with the ssh key listed in the account system, the same one you may already use for CVS access. You may also have sudo access on some of the machines relevant to your area of expertise (the password will the same as the one you use in the Fedora Account System). WARNING: Do not change system configurations or settings. Right now that has to happen through a separate mechanism that isn't yet external. I will also personally get on your case if you start changing systems without working with the rest of the 'team'. I would love to get more people helping enhance our infrastructure, so if you believe it would help for you to have login access and I left you out, please let me know! Best, -- Elliot From qspencer at ieee.org Wed Nov 16 03:42:03 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 15 Nov 2005 21:42:03 -0600 Subject: Shell access to fedora.redhat.com machines In-Reply-To: References: Message-ID: <437AAA8B.30102@ieee.org> Elliot Lee wrote: >Hi all, > >I've set things up so we can start to allow shell accounts on >*.fedora.redhat.com (and hopefully *.fedoraproject.org, RSN), enabling >more people to create and enhance Fedora infrastructure. There are now >three groups in the account system - sysadmin-build (for people >maintaining the build systems), sysadmin-web (for people hacking on web >infrastructure) and sysadmin (for people doing general infrastructure >maintenance). > >These shell accounts are only to be used for Fedora project-related stuff >- please don't put any personal materials or services or 'stuff' in them. > > What about shell access to debug problems on architectures we don't otherwise have access to? I don't necessarily have the time to work on Fedora infrastructure projects, but I have occaisionally run into build problems, with x86_64 for example, where debugging has been done via reading build logs and asking questions on mailing lists when I might have more quickly found the problem on my own given shell access to the right machine. -Quentin From dwmw2 at infradead.org Wed Nov 16 07:13:59 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 16 Nov 2005 07:13:59 +0000 Subject: Shell access to fedora.redhat.com machines In-Reply-To: <437AAA8B.30102@ieee.org> References: <437AAA8B.30102@ieee.org> Message-ID: <1132125239.28963.46.camel@baythorne.infradead.org> On Tue, 2005-11-15 at 21:42 -0600, Quentin Spencer wrote: > What about shell access to debug problems on architectures we don't > otherwise have access to? If the answer to that is 'no' I can certainly provide access to PPC machines for package maintainers in need of it. -- dwmw2 From misa at redhat.com Wed Nov 16 13:41:52 2005 From: misa at redhat.com (Mihai Ibanescu) Date: Wed, 16 Nov 2005 08:41:52 -0500 Subject: python 2.4.2 Message-ID: <20051116134152.GA26570@abulafia.devel.redhat.com> Hello, Just a heads-up - I updated python to 2.4.2 in rawhide (and forgot to rebuild python-docs which means last night's tree has this broken dependency - just uninstall python-docs to get the latest python). Please report any breakage (hopefully none...) Thanks, Misa From sopwith at redhat.com Thu Nov 17 21:20:11 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 17 Nov 2005 16:20:11 -0500 (EST) Subject: Shell access to fedora.redhat.com machines In-Reply-To: <1132125239.28963.46.camel@baythorne.infradead.org> References: <437AAA8B.30102@ieee.org> <1132125239.28963.46.camel@baythorne.infradead.org> Message-ID: On Wed, 16 Nov 2005, David Woodhouse wrote: > On Tue, 2005-11-15 at 21:42 -0600, Quentin Spencer wrote: > > What about shell access to debug problems on architectures we don't > > otherwise have access to? > > If the answer to that is 'no' I can certainly provide access to PPC > machines for package maintainers in need of it. At this point, I don't feel comfortable giving out access to all the developers, so it would be great if someone has a directly-on-the-net system that can be made available for debugging purposes. An alternative is to use one of the shell accounts that I believe sourceforge gives out... Best, -- Elliot From tburke at redhat.com Fri Nov 18 02:23:25 2005 From: tburke at redhat.com (Tim Burke) Date: Thu, 17 Nov 2005 21:23:25 -0500 Subject: Fedora general improvements input survey invitation Message-ID: <437D3B1D.7050007@redhat.com> The Fedora Core team invites you to participate in a survey to help identify the major ways in which Fedora can be improved for the benefit of the community. The survey consists of 10 questions involving Fedora Core and Fedora Extras. We are greatly interested in your views and hope you can share your thoughts with us. The survey is available at: http://www.keysurvey.com/survey/85928/1078/ The survey is enabled now and will remain open for input until Wednesday, November 30. Thanks in advance for helping us to make Fedora better for all involved. Upon conclusion of the survey, a summary of the results will be shared. From skvidal at phy.duke.edu Sun Nov 27 20:16:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 27 Nov 2005 15:16:31 -0500 Subject: Core BrainStorm Message-ID: <1133122591.21208.47.camel@cutter> Hi Folks, I setup a wiki page to get some ideas together about defining criteria for what is and is not core: http://fedoraproject.org/wiki/CoreBrainStorm What'd I'd love to see here is more help defining the criteria for what makes a package core. Then we can apply those criteria to each package in core and see if it still belongs there. I've got a few criteria that _might_ work and a couple of given assumptions to work from. So if you have any ideas discuss them here and post criteria to the brainstorm page. Thanks, -sv From j.w.r.degoede at hhs.nl Sun Nov 27 20:45:05 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 27 Nov 2005 21:45:05 +0100 Subject: major libgda and libgnomedb upgrade notice Message-ID: <438A1AD1.3050809@hhs.nl> Hi all, I'm about to request a build of much newer versions of libgda and libgnomedb: 1.9.100 this is a .so-name changing upgrade. Is their anyone / any package out there besides gnumeric (which I maintain) which uses libgda and/or libgnomedb? I won't push the build until my goffice package has been approved since without that I can't rebuild gnumeric (which is the reason todo this upgrade in the first place), so that creates a nice window for anyone to respond. Regards, Hans