From skvidal at phy.duke.edu Mon Aug 1 01:04:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 31 Jul 2005 21:04:52 -0400 Subject: More status on the Extras buildsystem In-Reply-To: <1122838237.25925.139.camel@ernie> References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> Message-ID: <1122858292.7609.46.camel@cutter> > cvs co rpms/opendap rpms/nco > for i in opendap nco ; do > for j in FC-3 FC-4 devel ; do > ( cd rpms/${i}/${j} ; make tag ; make plague ) > done > done > > which seems to work just fine judging by the output generated. > Unfortunately, the command > > plague-client list email ed at eh3.com > > lists only the three udunits builds that I submitted yesterday using, > AFAICT, exactly the same procedure. And they seem to have built without > any problems. > > So, what went wrong this time? Can anyone help me figure it out...? > I dunno. The log recorded the request for them but they're not in the db. -sv From ed at eh3.com Mon Aug 1 02:39:49 2005 From: ed at eh3.com (Ed Hill) Date: Sun, 31 Jul 2005 22:39:49 -0400 Subject: More status on the Extras buildsystem In-Reply-To: <1122858292.7609.46.camel@cutter> References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> <1122858292.7609.46.camel@cutter> Message-ID: <1122863990.25925.158.camel@ernie> On Sun, 2005-07-31 at 21:04 -0400, seth vidal wrote: > > cvs co rpms/opendap rpms/nco > > for i in opendap nco ; do > > for j in FC-3 FC-4 devel ; do > > ( cd rpms/${i}/${j} ; make tag ; make plague ) > > done > > done > > > > which seems to work just fine judging by the output generated. > > Unfortunately, the command > > > > plague-client list email ed at eh3.com > > > > lists only the three udunits builds that I submitted yesterday using, > > AFAICT, exactly the same procedure. And they seem to have built without > > any problems. > > > > So, what went wrong this time? Can anyone help me figure it out...? > > I dunno. The log recorded the request for them but they're not in the > db. Thank you for looking into it. In the mean time, I've requested builds for opendap and nco with "make build" and will be happy to re-submit with plague-client if it helps. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From skvidal at phy.duke.edu Mon Aug 1 06:00:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 02:00:49 -0400 Subject: Cannot get mock to work In-Reply-To: <1122805842.1285.23.camel@localhost.localdomain> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> <1122733470.7609.12.camel@cutter> <1122800750.1285.11.camel@localhost.localdomain> <1122801137.7609.32.camel@cutter> <1122805842.1285.23.camel@localhost.localdomain> Message-ID: <1122876049.7609.54.camel@cutter> On Sun, 2005-07-31 at 13:30 +0300, Ville Skytt? wrote: > On Sun, 2005-07-31 at 05:12 -0400, seth vidal wrote: > > On Sun, 2005-07-31 at 12:05 +0300, Ville Skytt? wrote: > > > On Sat, 2005-07-30 at 10:24 -0400, seth vidal wrote: > > > > > > > 1. make up mock and plague webpages and release places so I don't have > > > > to keep putting them in ~skvidal off of linux.duke.edu :) > > > > > > How about keeping the FE CVS populated with up to date versions of mock > > > and plague (the latter apparently needs importing, dunno about the state > > > of the former)? Even if the actual packages are not built and shipped > > > yet, I think this would make things easier. > > > > but it already exists in fedora cvs. > > > > /cvs/fedora/mock > > Sure, and I believe plague is also somewhere there. But I mentioned and > asked about "FE CVS", in other words, the usual Extras packages CVS tree > just like all other packages. So that people could just "make build" > and nobody would have to use ~skvidal off of linux.duke.edu. > but we haven't made a release of 0.4 yet. So what am I supposed to keep FE CVS updated with? what tarballs would I have? -sv From skvidal at phy.duke.edu Mon Aug 1 06:38:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 02:38:36 -0400 Subject: tobuild file In-Reply-To: <87fytx4kbh.fsf@kosh.bigo.ensc.de> References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> Message-ID: <1122878317.7609.58.camel@cutter> On Fri, 2005-07-29 at 19:02 +0200, Enrico Scholz wrote: > skvidal at phy.duke.edu (seth vidal) writes: > > > Unless you have a compelling reason please don't submit anything new to > > the tobuild file. Try out the 'make plague' option and report any > > problems you have. > > plague seems to try to connect directly with the buildserver. This will > not work in most corporate or complex environments: I'd wager the vast majority of plague users are going to be coming at it from a corporate environment. This is a hobbyist distribution, remember? As for complex environments - its a single port you need to connect to outbound. > | [ensc at kosh ~]$ plague-client list_builders > | Error connecting to build server: '(110, 'Connection timed out')' > > From the packet-filter: > | [drop] IN=eth0 OUT=eth2 SRC=192.168.46.2 DST=152.3.220.164 LEN=60 TOS=0x00 PREC=0x00 TTL=74 ID=15979 DF PROTO=TCP SPT=38501 DPT=8887 SEQ=3481872747 ACK=0 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0 OPT (020405B40402080A575FC6D00000000001030302) > > ($https_proxy is set to a correctly) > > > You will have to add proxy support and let the buildserver listen on > standard ports (443 would be appropriate as CONNECT is usually allowed > for this ports). I think proxy support should be added but switching things to 443 is probably not going to happen. -sv From skvidal at phy.duke.edu Mon Aug 1 06:39:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 02:39:43 -0400 Subject: tobuild file In-Reply-To: <1122878317.7609.58.camel@cutter> References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> Message-ID: <1122878384.7609.60.camel@cutter> On Mon, 2005-08-01 at 02:38 -0400, seth vidal wrote: > On Fri, 2005-07-29 at 19:02 +0200, Enrico Scholz wrote: > > skvidal at phy.duke.edu (seth vidal) writes: > > > > > Unless you have a compelling reason please don't submit anything new to > > > the tobuild file. Try out the 'make plague' option and report any > > > problems you have. > > > > plague seems to try to connect directly with the buildserver. This will > > not work in most corporate or complex environments: > > I'd wager the vast majority of plague users are going to be coming at it should be a 'not' right here ^ > from a corporate environment. This is a hobbyist distribution, remember? -sv From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 1 06:58:23 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 01 Aug 2005 08:58:23 +0200 Subject: tobuild file In-Reply-To: <1122878317.7609.58.camel@cutter> (seth vidal's message of "Mon, 01 Aug 2005 02:38:36 -0400") References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> Message-ID: <87slxup2i8.fsf@kosh.bigo.ensc.de> skvidal at phy.duke.edu (seth vidal) writes: >> plague seems to try to connect directly with the buildserver. This will >> not work in most corporate or complex environments: > > I'd wager the vast majority of plague users are going to be coming at it > from a corporate environment. This is a hobbyist distribution, remember? This should not stop us from doing things right from the beginning. *Enforcing* usage of a half-baked plague-client (and ignoring the current 'make build') is the wrong way. > I think proxy support should be added but switching things to 443 is > probably not going to happen. Why not tunnel it over an exiting https server? E.g. over https://bugzilla.redhat.com/plague; this should be doable with Apache httpd's ProxyPass directive. Enrico From skvidal at phy.duke.edu Mon Aug 1 07:21:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 03:21:57 -0400 Subject: tobuild file In-Reply-To: <87slxup2i8.fsf@kosh.bigo.ensc.de> References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> <87slxup2i8.fsf@kosh.bigo.ensc.de> Message-ID: <1122880917.7609.79.camel@cutter> On Mon, 2005-08-01 at 08:58 +0200, Enrico Scholz wrote: > skvidal at phy.duke.edu (seth vidal) writes: > > >> plague seems to try to connect directly with the buildserver. This will > >> not work in most corporate or complex environments: > > > > I'd wager the vast majority of plague users are going to be coming at it > > from a corporate environment. This is a hobbyist distribution, remember? > > This should not stop us from doing things right from the beginning. > *Enforcing* usage of a half-baked plague-client (and ignoring the > current 'make build') is the wrong way. I take issue that doing things the way you've suggested is 'right'. Programming for the corner case is not 'right' nor sane. You program for the common case and move out to cover the oddball options if you _HAVE_ to. I take more issue that there is anything half-baked about plague or plague-client. Just b/c it doesn't support an infrastructure that doesn't allow arbitrary outbound connections doesn't mean it is half-baked. oh and the current 'make build' way relies on me uploading them, manually, from time to time using plague. So 'ignoring the whole make build' is entirely the point. make build will become make plague sometime soon. > Why not tunnel it over an exiting https server? E.g. over > https://bugzilla.redhat.com/plague; this should be doable with Apache > httpd's ProxyPass directive. b/c I doubt seriously red hat is going to allow that sort of misc cruft to live on their bugzilla server(s). Now, we can do something with this from another machine but I'm still wondering why we're inventing layers of indirection for an extremely isolated case. -sv From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 1 07:39:42 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 01 Aug 2005 09:39:42 +0200 Subject: tobuild file In-Reply-To: <1122880917.7609.79.camel@cutter> (seth vidal's message of "Mon, 01 Aug 2005 03:21:57 -0400") References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> <87slxup2i8.fsf@kosh.bigo.ensc.de> <1122880917.7609.79.camel@cutter> Message-ID: <87oe8ip0ld.fsf@kosh.bigo.ensc.de> skvidal at phy.duke.edu (seth vidal) writes: >> >> plague seems to try to connect directly with the buildserver. This will >> >> not work in most corporate or complex environments: >> > >> > I'd wager the vast majority of plague users are going to be coming at it >> > from a corporate environment. This is a hobbyist distribution, remember? >> >> This should not stop us from doing things right from the beginning. >> *Enforcing* usage of a half-baked plague-client (and ignoring the >> current 'make build') is the wrong way. > > I take issue that doing things the way you've suggested is 'right'. > Programming for the corner case is not 'right' nor sane. You program > for the common case Proxy support is a common case which should be implemented in all network aware applications. Well-known ports should be used for all public services. > I take more issue that there is anything half-baked about plague or > plague-client. Just b/c it doesn't support an infrastructure that > doesn't allow arbitrary outbound connections doesn't mean it is > half-baked. Every HTTP based application without proxy support is half-baked. > oh and the current 'make build' way relies on me uploading them, > manually, from time to time using plague. So 'ignoring the whole make > build' is entirely the point. make build will become make plague > sometime soon. Hopefully, plague will be finished then... >> Why not tunnel it over an exiting https server? E.g. over >> https://bugzilla.redhat.com/plague; this should be doable with Apache >> httpd's ProxyPass directive. > > b/c I doubt seriously red hat is going to allow that sort of misc cruft > to live on their bugzilla server(s). It should be only four additional statements in httpd.conf; e.g. | SSLProxyEngine on | ProxyVia on | ProxyPass /plague/ https://the-buildhost/ | ProxyPassReverse /people/ https://the-buildhost/ > Now, we can do something with this from another machine but I'm still > wondering why we're inventing layers of indirection for an extremely > isolated case. Because network applications resp. public services should be as firewall friendly as possible. XML-RPC is HTTP based and allows this without much effort. So why stop at the current state just because you think that it is enough for the most users? Enrico From ville.skytta at iki.fi Mon Aug 1 07:51:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 01 Aug 2005 10:51:27 +0300 Subject: Cannot get mock to work In-Reply-To: <1122876049.7609.54.camel@cutter> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> <1122733470.7609.12.camel@cutter> <1122800750.1285.11.camel@localhost.localdomain> <1122801137.7609.32.camel@cutter> <1122805842.1285.23.camel@localhost.localdomain> <1122876049.7609.54.camel@cutter> Message-ID: <1122882687.10448.14.camel@localhost.localdomain> On Mon, 2005-08-01 at 02:00 -0400, seth vidal wrote: > but we haven't made a release of 0.4 yet. So what am I supposed to keep > FE CVS updated with? what tarballs would I have? Uh... the same ones you didn't want to keep putting in ~skvidal on linux.duke.edu? From tmraz at redhat.com Mon Aug 1 08:20:32 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 01 Aug 2005 10:20:32 +0200 Subject: Dropping authconfig TUI? Message-ID: <1122884433.5523.16.camel@perun.redhat.usu> I'm in process of refactoring and rewriting authconfig (alias system-config-authentication). The first step is rewriting most of the C code in Python. This should allow much easier extensibility and refactoring possibilities. I'd like to drop the Newt text UI from authconfig. The main reason isn't the Python rewrite but future improvements which I'd like to do only in GUI. The TUI has limited possibilities (especially the usable screen size as it must be designed for 80x24 terminals). This wouldn't mean that authconfig won't be usable without X display because there still remains the command line interface with -- enable/disable options, which is IMO much more useful for experienced sysadmins. If you have some serious objections, please speak up. -- Tomas Mraz From petersen at redhat.com Mon Aug 1 09:44:31 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 01 Aug 2005 18:44:31 +0900 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050729153325.2e7738d5@nausicaa.camperquake.de> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> <20050729153325.2e7738d5@nausicaa.camperquake.de> Message-ID: <42EDEEFF.9010700@redhat.com> Ralf Ertzinger wrote: > Jens Petersen wrote: >>Indeed people who don't need -devel packages don't need -static either. >>My concern is developers having to download static libs that they never >>use. > > Given the fact that selecting "development" in the installation process > will give you almost each and every -devel package the system has to > offer anyway I thinks this is a kind of moot point. Disk space is cheap. I beg to disagree: to me the issue is download time and bandwidth (think "yum upgrade"), but yes diskspace is also an issue. -devel packages without static will typically be much smaller than with, and in some cases very significantly smaller. Most Fedora developers do not need static libs I believe and there is no reason why everyone should need to download them when only a minority use them. Jens From petersen at redhat.com Mon Aug 1 09:48:53 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 01 Aug 2005 18:48:53 +0900 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122647305.8768.21.camel@bree.local.net> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> <20050729153325.2e7738d5@nausicaa.camperquake.de> <1122647305.8768.21.camel@bree.local.net> Message-ID: <42EDF005.5000005@redhat.com> Jeremy Katz wrote: > And if the static libs are split out, then it will give you the -static > packages as well. But at a huge cost of maintenance for the comps file > + overhead of more headers in the rpmdb (with duplicated changelogs, > etc). Well I was rather hoping that -static packages would not be included in comps, or at least not by default anyway. I certainly don't want them installed by default since I never really use them. To me it would be ok not to include them in comps at all, but no doubt other will disagree. Jens From petersen at redhat.com Mon Aug 1 09:54:11 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 01 Aug 2005 18:54:11 +0900 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <604aa791050729094658c38860@mail.gmail.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> <20050729153325.2e7738d5@nausicaa.camperquake.de> <1122647305.8768.21.camel@bree.local.net> <604aa791050729094658c38860@mail.gmail.com> Message-ID: <42EDF143.6050605@redhat.com> Jeff Spaleta wrote: > What is the recommended process for people who desire building a > static binary.. for say in-house usage? If Fedora as a general rule > is removing static libs from binary packages... Well it doesn't look removal of most static libs is going to happen, since there is some demand for static libs from portability and ISVs. Jens From petersen at redhat.com Mon Aug 1 10:02:19 2005 From: petersen at redhat.com (Jens Petersen) Date: Mon, 01 Aug 2005 19:02:19 +0900 Subject: tobuild file In-Reply-To: <1122878317.7609.58.camel@cutter> References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> Message-ID: <42EDF32B.6040304@redhat.com> seth vidal wrote: > I'd wager the vast majority of plague users are not going to be coming at it > from a corporate environment. I wouldn't be so sure about that. I could imagine quite a lot of Fedora Extras contributors use it at work too. > This is a hobbyist distribution, remember? For developers yes, but not it is not a toy distro... Jens From dwmw2 at infradead.org Mon Aug 1 10:45:02 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 01 Aug 2005 11:45:02 +0100 Subject: tobuild file In-Reply-To: <42EDF32B.6040304@redhat.com> References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> <42EDF32B.6040304@redhat.com> Message-ID: <1122893103.8317.75.camel@baythorne.infradead.org> On Mon, 2005-08-01 at 19:02 +0900, Jens Petersen wrote: > seth vidal wrote: > > I'd wager the vast majority of plague users are not going to be coming at it > > from a corporate environment. > > I wouldn't be so sure about that. I could imagine quite a lot of > Fedora Extras contributors use it at work too. Yes, but many work environments _are_ set up with proper access to the outside world via NAT. We're not talking about _everyone_ who uses it from work; just those with broken connectivity. And if their connectivity is broken enough that it doesn't allow outgoing connections from plague, then it probably doesn't allow SSH either -- so they can't actually commit to CVS anyway. I don't see that we have to pander to their brokenness. -- dwmw2 From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 1 11:26:59 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 01 Aug 2005 13:26:59 +0200 Subject: tobuild file In-Reply-To: <1122893103.8317.75.camel@baythorne.infradead.org> (David Woodhouse's message of "Mon, 01 Aug 2005 11:45:02 +0100") References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> <42EDF32B.6040304@redhat.com> <1122893103.8317.75.camel@baythorne.infradead.org> Message-ID: <87k6j5q4n0.fsf@kosh.bigo.ensc.de> dwmw2 at infradead.org (David Woodhouse) writes: >> > I'd wager the vast majority of plague users are not going to be >> > coming at it from a corporate environment. >> >> I wouldn't be so sure about that. I could imagine quite a lot of >> Fedora Extras contributors use it at work too. > > Yes, but many work environments _are_ set up with proper access to the > outside world via NAT. We're not talking about _everyone_ who uses it > from work; just those with broken connectivity. Do you have numbers about the percentage of full-access vs. restricted-access networks? My feeling is, that the large part of work environments does not allow direct access but only a restricted subset (perhaps ssh) or forbids it completely and enforces proxy usage. > And if their connectivity is broken enough that it doesn't allow > outgoing connections from plague, then it probably doesn't allow SSH > either -- so they can't actually commit to CVS anyway. ACK, 'make build' is already a pain and forces me to setup yet another tunnel. (IMO, CVS was a bad choice for the Fedora source code management. SVN and GNU arch are much more firewall friendly because their used libraries know how to use proxies). > I don't see that we have to pander to their brokenness. Why brokeness? These environments are providing usually HTTP proxies and every HTTP based application should know how to use them. When not, these applications but not the environments are broken. Enrico From paul at city-fan.org Mon Aug 1 11:57:34 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 01 Aug 2005 12:57:34 +0100 Subject: More status on the Extras buildsystem In-Reply-To: <1122863990.25925.158.camel@ernie> References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> <1122858292.7609.46.camel@cutter> <1122863990.25925.158.camel@ernie> Message-ID: <1122897455.2851.178.camel@laurel.intra.city-fan.org> On Sun, 2005-07-31 at 22:39 -0400, Ed Hill wrote: > On Sun, 2005-07-31 at 21:04 -0400, seth vidal wrote: > > > cvs co rpms/opendap rpms/nco > > > for i in opendap nco ; do > > > for j in FC-3 FC-4 devel ; do > > > ( cd rpms/${i}/${j} ; make tag ; make plague ) > > > done > > > done > > > > > > which seems to work just fine judging by the output generated. > > > Unfortunately, the command > > > > > > plague-client list email ed at eh3.com > > > > > > lists only the three udunits builds that I submitted yesterday using, > > > AFAICT, exactly the same procedure. And they seem to have built without > > > any problems. > > > > > > So, what went wrong this time? Can anyone help me figure it out...? > > > > I dunno. The log recorded the request for them but they're not in the > > db. > > Thank you for looking into it. > > In the mean time, I've requested builds for opendap and nco with "make > build" and will be happy to re-submit with plague-client if it helps. I've run "make plague" for spamass-milter-0_3_0-8_fc5 twice today. Both times it came back saying "Package spamass-milter enqueued." Running "plague-client list" reveals no new entries in the queue; the last one remains as: 249: dejavu-fonts (dejavu-fonts-1_12-1) nicolas.mailhot at laposte.net waiting I had this working on Friday, building packages using "make plague". What gives? Paul. -- Paul Howarth From jspaleta at gmail.com Mon Aug 1 12:20:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 1 Aug 2005 08:20:14 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42EDF143.6050605@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> <20050729153325.2e7738d5@nausicaa.camperquake.de> <1122647305.8768.21.camel@bree.local.net> <604aa791050729094658c38860@mail.gmail.com> <42EDF143.6050605@redhat.com> Message-ID: <604aa79105080105207e983fa6@mail.gmail.com> On 8/1/05, Jens Petersen wrote: > Well it doesn't look removal of most static libs is going to happen, its already a policy to exclude static libraries in Extras. -jef http://www.fedoraproject.org/wiki/PackagingGuidelines Exclusion of Static Libraries Packages including libraries should exclude static libs as far as possible (eg by configuring with --disable-static). Static libraries should only be included in exceptional circumstances. Also applications linking against libraries should as far as possible link against shared libraries not static versions. From skvidal at phy.duke.edu Mon Aug 1 13:05:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 09:05:12 -0400 Subject: tobuild file In-Reply-To: <87oe8ip0ld.fsf@kosh.bigo.ensc.de> References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> <87slxup2i8.fsf@kosh.bigo.ensc.de> <1122880917.7609.79.camel@cutter> <87oe8ip0ld.fsf@kosh.bigo.ensc.de> Message-ID: <1122901512.7609.85.camel@cutter> > Proxy support is a common case which should be implemented in all > network aware applications. Well-known ports should be used for all > public services. And that's fine. But seeing as you're the only one experiencing this thus far I'd expect you to spend some time patching the problem. > > oh and the current 'make build' way relies on me uploading them, > > manually, from time to time using plague. So 'ignoring the whole make > > build' is entirely the point. make build will become make plague > > sometime soon. > > Hopefully, plague will be finished then... If you send in a patch, I'm sure it will be. > Because network applications resp. public services should be as firewall > friendly as possible. XML-RPC is HTTP based and allows this without much > effort. So why stop at the current state just because you think that it > is enough for the most users? I think you're the only user who has had this problem. -sv From skvidal at phy.duke.edu Mon Aug 1 13:05:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 09:05:49 -0400 Subject: Cannot get mock to work In-Reply-To: <1122882687.10448.14.camel@localhost.localdomain> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> <1122733470.7609.12.camel@cutter> <1122800750.1285.11.camel@localhost.localdomain> <1122801137.7609.32.camel@cutter> <1122805842.1285.23.camel@localhost.localdomain> <1122876049.7609.54.camel@cutter> <1122882687.10448.14.camel@localhost.localdomain> Message-ID: <1122901549.7609.87.camel@cutter> On Mon, 2005-08-01 at 10:51 +0300, Ville Skytt? wrote: > On Mon, 2005-08-01 at 02:00 -0400, seth vidal wrote: > > > but we haven't made a release of 0.4 yet. So what am I supposed to keep > > FE CVS updated with? what tarballs would I have? > > Uh... the same ones you didn't want to keep putting in ~skvidal on > linux.duke.edu? > There have been no others. The version of mock in fe cvs was (until yesterday) the latest version of mock released. -sv From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 1 13:26:24 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 01 Aug 2005 15:26:24 +0200 Subject: tobuild file In-Reply-To: <1122901512.7609.85.camel@cutter> (seth vidal's message of "Mon, 01 Aug 2005 09:05:12 -0400") References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> <87slxup2i8.fsf@kosh.bigo.ensc.de> <1122880917.7609.79.camel@cutter> <87oe8ip0ld.fsf@kosh.bigo.ensc.de> <1122901512.7609.85.camel@cutter> Message-ID: <87fyttpz3z.fsf@kosh.bigo.ensc.de> skvidal at phy.duke.edu (seth vidal) writes: >> > oh and the current 'make build' way relies on me uploading them, >> > manually, from time to time using plague. So 'ignoring the whole >> > make build' is entirely the point. make build will become make >> > plague sometime soon. >> >> Hopefully, plague will be finished then... > > If you send in a patch, I'm sure it will be. Thanks; but I do not want to waste yet more time with patches which are ignored by you. So I will just use 'make build' until plague is fixed. Enrico From skvidal at phy.duke.edu Mon Aug 1 13:34:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 09:34:11 -0400 Subject: tobuild file In-Reply-To: <87fyttpz3z.fsf@kosh.bigo.ensc.de> References: <1122619834.2521.13.camel@cutter> <87fytx4kbh.fsf@kosh.bigo.ensc.de> <1122878317.7609.58.camel@cutter> <87slxup2i8.fsf@kosh.bigo.ensc.de> <1122880917.7609.79.camel@cutter> <87oe8ip0ld.fsf@kosh.bigo.ensc.de> <1122901512.7609.85.camel@cutter> <87fyttpz3z.fsf@kosh.bigo.ensc.de> Message-ID: <1122903251.7609.91.camel@cutter> On Mon, 2005-08-01 at 15:26 +0200, Enrico Scholz wrote: > skvidal at phy.duke.edu (seth vidal) writes: > > >> > oh and the current 'make build' way relies on me uploading them, > >> > manually, from time to time using plague. So 'ignoring the whole > >> > make build' is entirely the point. make build will become make > >> > plague sometime soon. > >> > >> Hopefully, plague will be finished then... > > > > If you send in a patch, I'm sure it will be. > > Thanks; but I do not want to waste yet more time with patches which are > ignored by you. So I will just use 'make build' until plague is fixed. I've not ignored any patches. I outright rejected the patch you're talking about. Just b/c someone doesn't accept your patch doesn't mean they're ignoring you. It means they don't like what you were did in the patch. And I didn't. But if that's your attitude then I guess plague-client will never be fixed for the corner case you're in. -sv From paul at city-fan.org Mon Aug 1 15:44:26 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 01 Aug 2005 16:44:26 +0100 Subject: More status on the Extras buildsystem In-Reply-To: <1122897455.2851.178.camel@laurel.intra.city-fan.org> References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> <1122858292.7609.46.camel@cutter> <1122863990.25925.158.camel@ernie> <1122897455.2851.178.camel@laurel.intra.city-fan.org> Message-ID: <1122911066.2851.244.camel@laurel.intra.city-fan.org> On Mon, 2005-08-01 at 12:57 +0100, Paul Howarth wrote: > On Sun, 2005-07-31 at 22:39 -0400, Ed Hill wrote: > > On Sun, 2005-07-31 at 21:04 -0400, seth vidal wrote: > > > > cvs co rpms/opendap rpms/nco > > > > for i in opendap nco ; do > > > > for j in FC-3 FC-4 devel ; do > > > > ( cd rpms/${i}/${j} ; make tag ; make plague ) > > > > done > > > > done > > > > > > > > which seems to work just fine judging by the output generated. > > > > Unfortunately, the command > > > > > > > > plague-client list email ed at eh3.com > > > > > > > > lists only the three udunits builds that I submitted yesterday using, > > > > AFAICT, exactly the same procedure. And they seem to have built without > > > > any problems. > > > > > > > > So, what went wrong this time? Can anyone help me figure it out...? > > > > > > I dunno. The log recorded the request for them but they're not in the > > > db. > > > > Thank you for looking into it. > > > > In the mean time, I've requested builds for opendap and nco with "make > > build" and will be happy to re-submit with plague-client if it helps. > > I've run "make plague" for spamass-milter-0_3_0-8_fc5 twice today. Both > times it came back saying "Package spamass-milter enqueued." > > Running "plague-client list" reveals no new entries in the queue; the > last one remains as: > > 249: dejavu-fonts (dejavu-fonts-1_12-1) nicolas.mailhot at laposte.net > waiting > > I had this working on Friday, building packages using "make plague". > What gives? I see that a number of jobs have now made it into the queue, including both of my requests (and some duplicates from other people too). I tried killing one of my duplicate jobs about 20 minutes ago by doing: $ plague-client kill 282 Shortly afterwards I received an email stating that the job had been killed. However, the page http://buildsys.fedoraproject.org/build-status/job.psp?uid=282 still shows that job as "building" and in fact the plague-client command has still not exited. This doesn't seem right... Paul. -- Paul Howarth From dcbw at redhat.com Mon Aug 1 16:03:09 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 1 Aug 2005 12:03:09 -0400 (EDT) Subject: More status on the Extras buildsystem In-Reply-To: <1122911066.2851.244.camel@laurel.intra.city-fan.org> References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> <1122858292.7609.46.camel@cutter> <1122863990.25925.158.camel@ernie> <1122897455.2851.178.camel@laurel.intra.city-fan.org> <1122911066.2851.244.camel@laurel.intra.city-fan.org> Message-ID: On Mon, 1 Aug 2005, Paul Howarth wrote: > I see that a number of jobs have now made it into the queue, including > both of my requests (and some duplicates from other people too). I tried > killing one of my duplicate jobs about 20 minutes ago by doing: > > $ plague-client kill 282 > > Shortly afterwards I received an email stating that the job had been > killed. However, the page > http://buildsys.fedoraproject.org/build-status/job.psp?uid=282 still > shows that job as "building" and in fact the plague-client command has > still not exited. This doesn't seem right... It appears that (as of last night) the build server was stuck in SSL_BIO_read() trying to receive data from hammer3. I killed the hammer3 plague-builder process, but the server didn't notice that because it was stuck in that function. Now the fix for this is to use socket timeouts, which essentially make the sockets non-blocking, but this leads to other problems (ie, socket.makefile() doesn't work well with socket.settimeout(), but we have to use makefile because the SSL sockets don't have a dup2()) that need to be dealt with as well. I hope that I can come up with some non-blocking solution here to deal with these issues. The worst thing is that these problems are completely non-reproducible and occur at random. The immediate solution is to restart the build server. Dan From paul at city-fan.org Mon Aug 1 16:08:53 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 01 Aug 2005 17:08:53 +0100 Subject: More status on the Extras buildsystem In-Reply-To: References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> <1122858292.7609.46.camel@cutter> <1122863990.25925.158.camel@ernie> <1122897455.2851.178.camel@laurel.intra.city-fan.org> <1122911066.2851.244.camel@laurel.intra.city-fan.org> Message-ID: <1122912533.2851.249.camel@laurel.intra.city-fan.org> On Mon, 2005-08-01 at 12:03 -0400, Dan Williams wrote: > On Mon, 1 Aug 2005, Paul Howarth wrote: > > I see that a number of jobs have now made it into the queue, including > > both of my requests (and some duplicates from other people too). I tried > > killing one of my duplicate jobs about 20 minutes ago by doing: > > > > $ plague-client kill 282 > > > > Shortly afterwards I received an email stating that the job had been > > killed. However, the page > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=282 still > > shows that job as "building" and in fact the plague-client command has > > still not exited. This doesn't seem right... > > It appears that (as of last night) the build server was stuck in SSL_BIO_read() > trying to receive data from hammer3. I killed the hammer3 plague-builder > process, but the server didn't notice that because it was stuck in that > function. > > Now the fix for this is to use socket timeouts, which essentially make the > sockets non-blocking, but this leads to other problems (ie, socket.makefile() > doesn't work well with socket.settimeout(), but we have to use makefile because > the SSL sockets don't have a dup2()) that need to be dealt with as well. I hope > that I can come up with some non-blocking solution here to deal with these > issues. The worst thing is that these problems are completely non-reproducible > and occur at random. > > The immediate solution is to restart the build server. Thanks; that caused my original "plague-client kill 282" to produce a traceback. I was then able to repeat the command, and it exited quickly with: $ plague-client kill 282 Success: job 282 killed. This time it does seem to have worked. There are still duplicates of gkrellm-freq-0_1_1-2_fc4 and dejavu-fonts-1_12-1_fc3 in the queue, so the owners of those packages may want to kill the dupes. Paul. -- Paul Howarth From smooge at gmail.com Mon Aug 1 16:28:43 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 1 Aug 2005 10:28:43 -0600 Subject: Dropping authconfig TUI? In-Reply-To: <1122884433.5523.16.camel@perun.redhat.usu> References: <1122884433.5523.16.camel@perun.redhat.usu> Message-ID: <80d7e4090508010928314c4aa7@mail.gmail.com> On 8/1/05, Tomas Mraz wrote: > I'm in process of refactoring and rewriting authconfig > (alias system-config-authentication). > > The first step is rewriting most of the C code in Python. This should > allow much easier extensibility and refactoring possibilities. > > I'd like to drop the Newt text UI from authconfig. The main reason isn't > the Python rewrite but future improvements which I'd like to do only in > GUI. The TUI has limited possibilities (especially the usable screen > size as it must be designed for 80x24 terminals). > > This wouldn't mean that authconfig won't be usable without X display > because there still remains the command line interface with -- > enable/disable options, which is IMO much more useful for experienced > sysadmins. > Well I do not have serious objections.. but I have found that the tui was much easier to use for most of my limited needs. Having a well documented command line tool though would be equivalent. I would also suggest that this be documented in a wider audience so it doesnt show up as the usual flame war about RH not telling anyone but a select audience what they are planning. It will instead be a flame-war about no TUI's for remote administration. By the way, I have to write a bunch of python TUI's at my secure undisclosed location.. what would be the best packages to look at for pointers on doing this? -- Stephen J Smoogen. CSIRT/Linux System Administrator From skvidal at phy.duke.edu Mon Aug 1 16:40:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 12:40:19 -0400 Subject: More status on the Extras buildsystem In-Reply-To: References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> <1122858292.7609.46.camel@cutter> <1122863990.25925.158.camel@ernie> <1122897455.2851.178.camel@laurel.intra.city-fan.org> <1122911066.2851.244.camel@laurel.intra.city-fan.org> Message-ID: <1122914419.3131.6.camel@cutter> On Mon, 2005-08-01 at 12:03 -0400, Dan Williams wrote: > On Mon, 1 Aug 2005, Paul Howarth wrote: > > I see that a number of jobs have now made it into the queue, including > > both of my requests (and some duplicates from other people too). I tried > > killing one of my duplicate jobs about 20 minutes ago by doing: > > > > $ plague-client kill 282 > > > > Shortly afterwards I received an email stating that the job had been > > killed. However, the page > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=282 still > > shows that job as "building" and in fact the plague-client command has > > still not exited. This doesn't seem right... > > It appears that (as of last night) the build server was stuck in SSL_BIO_read() > trying to receive data from hammer3. I killed the hammer3 plague-builder > process, but the server didn't notice that because it was stuck in that > function. > > Now the fix for this is to use socket timeouts, which essentially make the > sockets non-blocking, but this leads to other problems (ie, socket.makefile() > doesn't work well with socket.settimeout(), but we have to use makefile because > the SSL sockets don't have a dup2()) that need to be dealt with as well. I hope > that I can come up with some non-blocking solution here to deal with these > issues. The worst thing is that these problems are completely non-reproducible > and occur at random. > > The immediate solution is to restart the build server. > which we did, this morning, around 9:30 or so. -sv From skvidal at phy.duke.edu Mon Aug 1 16:44:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 12:44:28 -0400 Subject: Dropping authconfig TUI? In-Reply-To: <80d7e4090508010928314c4aa7@mail.gmail.com> References: <1122884433.5523.16.camel@perun.redhat.usu> <80d7e4090508010928314c4aa7@mail.gmail.com> Message-ID: <1122914668.3131.10.camel@cutter> On Mon, 2005-08-01 at 10:28 -0600, Stephen J. Smoogen wrote: > On 8/1/05, Tomas Mraz wrote: > > I'm in process of refactoring and rewriting authconfig > > (alias system-config-authentication). > > > > The first step is rewriting most of the C code in Python. This should > > allow much easier extensibility and refactoring possibilities. > > > > I'd like to drop the Newt text UI from authconfig. The main reason isn't > > the Python rewrite but future improvements which I'd like to do only in > > GUI. The TUI has limited possibilities (especially the usable screen > > size as it must be designed for 80x24 terminals). > > > > This wouldn't mean that authconfig won't be usable without X display > > because there still remains the command line interface with -- > > enable/disable options, which is IMO much more useful for experienced > > sysadmins. > > > > Well I do not have serious objections.. but I have found that the tui > was much easier to use for most of my limited needs. Having a well > documented command line tool though would be equivalent. I would also > suggest that this be documented in a wider audience so it doesnt show > up as the usual flame war about RH not telling anyone but a select > audience what they are planning. It will instead be a flame-war about > no TUI's for remote administration. > > By the way, I have to write a bunch of python TUI's at my secure > undisclosed location.. what would be the best packages to look at for > pointers on doing this? I use authconfig in %post of kickstarts to setup things w/o having to manually intervene. I don't care so much about the tui but I would hope a scriptable/single-command option would be available w/o the need for the X interface. -sv From dcbw at redhat.com Mon Aug 1 18:32:57 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 1 Aug 2005 14:32:57 -0400 (EDT) Subject: More status on the Extras buildsystem In-Reply-To: <1122914419.3131.6.camel@cutter> References: <1122610894.8768.17.camel@bree.local.net> <1122838237.25925.139.camel@ernie> <1122858292.7609.46.camel@cutter> <1122863990.25925.158.camel@ernie> <1122897455.2851.178.camel@laurel.intra.city-fan.org> <1122911066.2851.244.camel@laurel.intra.city-fan.org> <1122914419.3131.6.camel@cutter> Message-ID: On Mon, 1 Aug 2005, seth vidal wrote: > On Mon, 2005-08-01 at 12:03 -0400, Dan Williams wrote: > > On Mon, 1 Aug 2005, Paul Howarth wrote: > > > I see that a number of jobs have now made it into the queue, including > > > both of my requests (and some duplicates from other people too). I tried > > > killing one of my duplicate jobs about 20 minutes ago by doing: > > > > > > $ plague-client kill 282 > > > > > > Shortly afterwards I received an email stating that the job had been > > > killed. However, the page > > > http://buildsys.fedoraproject.org/build-status/job.psp?uid=282 still > > > shows that job as "building" and in fact the plague-client command has > > > still not exited. This doesn't seem right... > > > > It appears that (as of last night) the build server was stuck in SSL_BIO_read() > > trying to receive data from hammer3. I killed the hammer3 plague-builder > > process, but the server didn't notice that because it was stuck in that > > function. > > > > Now the fix for this is to use socket timeouts, which essentially make the > > sockets non-blocking, but this leads to other problems (ie, socket.makefile() > > doesn't work well with socket.settimeout(), but we have to use makefile because > > the SSL sockets don't have a dup2()) that need to be dealt with as well. I hope > > that I can come up with some non-blocking solution here to deal with these > > issues. The worst thing is that these problems are completely non-reproducible > > and occur at random. > > > > The immediate solution is to restart the build server. I think I've got a workable solution based on select() rather than setting socket timeouts, since timeouts also set the socket non-blocking. I won't know all the error conditions until we deploy it but we can fix those up as we go. So hopefully this will just make the server drop the builder on the floor rather than hanging and getting confused as is currently the case. Dan From orion at cora.nwra.com Mon Aug 1 20:38:00 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 01 Aug 2005 14:38:00 -0600 Subject: Cannot get mock to work In-Reply-To: References: <42EAA5B3.6040306@cora.nwra.com> Message-ID: <42EE8828.4040701@cora.nwra.com> Dan Williams wrote: > On Fri, 29 Jul 2005, Orion Poplawski wrote: > > >>I'm having trouble getting mock to setup the chroot environment. >>Specifically, the groupinstall build is failing with lots of rpm script >>errors: >> >>error: %post(libgcc-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 >>error: %post(glibc-common-2.3.5-10.i386) scriptlet failed, exit status 255 > > > Just for kicks, try turning SELinux off. 'setenforce 0' or modify > /etc/sysconfig/selinux. > > While mock should work correctly with selinux on, this is a lot like what I was > getting before Jeremy added selinux support to mock. > > Dan > Get the same errors in permissive (setenforce 0) mode. Do I need to turn selinux off completely? I'm somewhat loathe to... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From skvidal at phy.duke.edu Mon Aug 1 20:42:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 01 Aug 2005 16:42:06 -0400 Subject: Cannot get mock to work In-Reply-To: <42EE8828.4040701@cora.nwra.com> References: <42EAA5B3.6040306@cora.nwra.com> <42EE8828.4040701@cora.nwra.com> Message-ID: <1122928926.3131.26.camel@cutter> On Mon, 2005-08-01 at 14:38 -0600, Orion Poplawski wrote: > Dan Williams wrote: > > On Fri, 29 Jul 2005, Orion Poplawski wrote: > > > > > >>I'm having trouble getting mock to setup the chroot environment. > >>Specifically, the groupinstall build is failing with lots of rpm script > >>errors: > >> > >>error: %post(libgcc-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 > >>error: %post(glibc-common-2.3.5-10.i386) scriptlet failed, exit status 255 > > > > > > Just for kicks, try turning SELinux off. 'setenforce 0' or modify > > /etc/sysconfig/selinux. > > > > While mock should work correctly with selinux on, this is a lot like what I was > > getting before Jeremy added selinux support to mock. > > > > Dan > > > > Get the same errors in permissive (setenforce 0) mode. Do I need to > turn selinux off completely? I'm somewhat loathe to... try this out: http://fedoraproject.org/wiki/Projects/Mock download the mock-0.4.tar.gz file linked from the Download dir. rpmbuild -ta thatfile and install the rpm. see if that solves the selinux problem you were having. -sv From orion at cora.nwra.com Mon Aug 1 21:18:18 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 01 Aug 2005 15:18:18 -0600 Subject: Cannot get mock to work In-Reply-To: <1122928926.3131.26.camel@cutter> References: <42EAA5B3.6040306@cora.nwra.com> <42EE8828.4040701@cora.nwra.com> <1122928926.3131.26.camel@cutter> Message-ID: <42EE919A.4050602@cora.nwra.com> seth vidal wrote: > > try this out: > > http://fedoraproject.org/wiki/Projects/Mock > > download the mock-0.4.tar.gz file linked from the Download dir. > > rpmbuild -ta thatfile > > and install the rpm. > > see if that solves the selinux problem you were having. > > -sv Works with permissive or enforcing mode. Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rc040203 at freenet.de Tue Aug 2 14:01:25 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 02 Aug 2005 16:01:25 +0200 Subject: Build job 317 Inventory-2.1.5-12.fc4 hangs Message-ID: <1122991286.28553.74.camel@mccallum.corsepiu.local> Hi, Subject says all. x86_64 and i386 completed with 9 rsp. 10 minutes, but the ppc seems to hang. At least it reports "running/building" for ca. 2 hours. Ralf From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 3 15:22:21 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 3 Aug 2005 17:22:21 +0200 Subject: Build system questions Message-ID: <20050803172221.3e88bb02@python2> Hi, I've just submitted 2 builds using "make plague". My problem now is that I can't see any of them either in the web interface, or using plague-client. Not sure what might be going on, but I think that already happened to me 2 days ago, and by simply waiting a little I saw them pop up eventually. My questions/suggestions are : - Would it be possible to have plague-client display the job id assigned to the job that just got submitted? That would make things really easier to check the status of the job from there, without having to hunt for the job first. - When I go to : http://buildsys.fedoraproject.org/build-status/indiv.psp?email=my email Even with "Status: ALL", I see only my failed jobs, not my jobs I can see when I go to "Successful Builds" that are in "needsign" state. Little bug? Overall, I'm really impressed by the new build system, it's simply awesome and only getting better as the remaining bugs get squashed with it now being in production. Great work Daniel and Seth! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.93 1.45 1.07 From qspencer at ieee.org Wed Aug 3 15:26:47 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 03 Aug 2005 10:26:47 -0500 Subject: Build system questions In-Reply-To: <20050803172221.3e88bb02@python2> References: <20050803172221.3e88bb02@python2> Message-ID: <42F0E237.8070009@ieee.org> Matthias Saou wrote: >Hi, > >I've just submitted 2 builds using "make plague". My problem now is that I >can't see any of them either in the web interface, or using plague-client. >Not sure what might be going on, but I think that already happened to me 2 >days ago, and by simply waiting a little I saw them pop up eventually. > >My questions/suggestions are : >- Would it be possible to have plague-client display the job id assigned >to the job that just got submitted? That would make things really easier >to check the status of the job from there, without having to hunt for the >job first. >- When I go to : >http://buildsys.fedoraproject.org/build-status/indiv.psp?email=my email >Even with "Status: ALL", I see only my failed jobs, not my jobs I can see >when I go to "Successful Builds" that are in "needsign" state. Little bug? > >Overall, I'm really impressed by the new build system, it's simply awesome >and only getting better as the remaining bugs get squashed with it now >being in production. Great work Daniel and Seth! > >Matthias > > I think something's up with the build system, too. I submitted a build earlier today and for an hour or so it showed up in the plague-client listing as in the "prep" stage, but not on the web interface. I've since killed it for unrelated reasons, so it's not there now. Everything was working fine yesterday. Maybe something in the chain got hung up? I agree with all the comments about the new build system, also. -Quentin From ed at eh3.com Wed Aug 3 16:14:42 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 03 Aug 2005 12:14:42 -0400 Subject: Build system questions In-Reply-To: <42F0E237.8070009@ieee.org> References: <20050803172221.3e88bb02@python2> <42F0E237.8070009@ieee.org> Message-ID: <1123085682.21460.80.camel@ernie> On Wed, 2005-08-03 at 10:26 -0500, Quentin Spencer wrote: > Matthias Saou wrote: > > >Hi, > > > >I've just submitted 2 builds using "make plague". My problem now is that I > >can't see any of them either in the web interface, or using plague-client. > >Not sure what might be going on, but I think that already happened to me 2 > >days ago, and by simply waiting a little I saw them pop up eventually. I'm seeing the same (?) problem as Matthias and there seems to be a bug opened for it at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165004 And "make plague" was working for me yesterday -- it just doesn't seem to be queueing any builds today. Perhaps something needs to be re- started? Ed ps - I'm also impressed by the new build system, particularly the nice web reports of its status! Thank you to everyone writing and maintaining it! -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From katzj at redhat.com Wed Aug 3 17:36:38 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 03 Aug 2005 13:36:38 -0400 Subject: Build system questions In-Reply-To: <1123085682.21460.80.camel@ernie> References: <20050803172221.3e88bb02@python2> <42F0E237.8070009@ieee.org> <1123085682.21460.80.camel@ernie> Message-ID: <42F100A6.3010004@redhat.com> Ed Hill wrote: > On Wed, 2005-08-03 at 10:26 -0500, Quentin Spencer wrote: >>>I've just submitted 2 builds using "make plague". My problem now is that I >>>can't see any of them either in the web interface, or using plague-client. >>>Not sure what might be going on, but I think that already happened to me 2 >>>days ago, and by simply waiting a little I saw them pop up eventually. > > I'm seeing the same (?) problem as Matthias and there seems to be a bug > opened for it at: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165004 > > And "make plague" was working for me yesterday -- it just doesn't seem > to be queueing any builds today. Perhaps something needs to be re- > started? Okay, I've kicked things and it looks like jobs are being accepted again for now. Ed -- I went ahead and queued up the fc4 nco build as my test case, so you shouldn't need to do it. I'll keep an eye on things through the afternoon to try to see if I can figure out the trigger for things going wrong. Thanks for everyone's continued patience as we work through some of the growing pains with the new system. Jeremy From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 3 18:08:44 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 3 Aug 2005 20:08:44 +0200 Subject: Build system questions In-Reply-To: <42F100A6.3010004@redhat.com> References: <20050803172221.3e88bb02@python2> <42F0E237.8070009@ieee.org> <1123085682.21460.80.camel@ernie> <42F100A6.3010004@redhat.com> Message-ID: <20050803200844.09911f8c@python2> Jeremy Katz wrote : > Okay, I've kicked things and it looks like jobs are being accepted again > for now. Ed -- I went ahead and queued up the fc4 nco build as my test > case, so you shouldn't need to do it. I'll keep an eye on things > through the afternoon to try to see if I can figure out the trigger for > things going wrong. > > Thanks for everyone's continued patience as we work through some of the > growing pains with the new system. The "growing pains" are well worth it : I've been watching in real time for the past 1/4h the jobs getting assigned and processed by the build system, and am simply AMAZED at the whole process... it's so neat!!! :-) Thanks for the "kick", btw ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.94 0.58 0.48 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Aug 3 22:29:44 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 4 Aug 2005 00:29:44 +0200 Subject: My first (ab)use of the CVS tags Message-ID: <20050804002944.2ec16c74@python2> Hi, Well, the subject is maybe a bit alarming, don't worry just yet :-) I wanted to get some maintainer's opinion about what I just did, which doesn't bother me much, but might be something for which consensus ends up being "don't do that, ever!" : I had forgot to commit a patch into CVS for synergy's FC-3 branch, and just committed the exact same files (except for that missing patch) to all FC-3, FC-4 and devel branches, tagged them and requested builds. Obviously, the FC-3 build immediately failed upon trying to build the source rpm, whereas the two others were going to build fine. The typical thing to do here would have been to bump the release and ask for a new build. But that would have meant bump the FC-4 and devel releases too to keep them in order (since I used "1%{?dist}" for all three), for nothing... so I tried something else. I manually tagged the FC-3 branch where the patch was now included as *-1_1_fc3 (where it previously was *-1_fc3) without actually changing the release nor anything else in the spec file, and asked plague to rebuild that new branch. I don't really know the implications of such a "trickery", other than the fact that looking at the tags of the FC-3 branch, one will think that a "1.1%{?dist}" release will have existed while this isn't he case. For me, this isn't much of a problem, since it avoided trying to cancel the other jobs, bumping releases, committing changes that aren't, asking for new builds... all things which would have been "for nothing". So... basically, I was just curious to know what the other maintainers thought of this, if it was something that should be banned, or if it could be acceptable in such circumstances. I personally don't really know, which is why I'm asking. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.15 0.18 0.12 From katzj at redhat.com Wed Aug 3 22:36:16 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 03 Aug 2005 18:36:16 -0400 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804002944.2ec16c74@python2> References: <20050804002944.2ec16c74@python2> Message-ID: <42F146E0.1090100@redhat.com> Matthias Saou wrote: > I manually tagged the FC-3 branch where the patch was now included as > *-1_1_fc3 (where it previously was *-1_fc3) without actually changing the > release nor anything else in the spec file, and asked plague to rebuild > that new branch. Inventive :-) > So... basically, I was just curious to know what the other maintainers > thought of this, if it was something that should be banned, or if it could > be acceptable in such circumstances. I personally don't really know, which > is why I'm asking. It's probably something that we should check in the buildsystem and explicitly disallow. At the same time, I think we also probably want to move to where we detect the things that cause a need for this earlier and be proactive about pointing out the problem. Jeremy From ivazquez at ivazquez.net Wed Aug 3 22:47:25 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 03 Aug 2005 18:47:25 -0400 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804002944.2ec16c74@python2> References: <20050804002944.2ec16c74@python2> Message-ID: <1123109245.12131.37.camel@ignacio.lan> On Thu, 2005-08-04 at 00:29 +0200, Matthias Saou wrote: > So... basically, I was just curious to know what the other maintainers > thought of this, if it was something that should be banned, or if it could > be acceptable in such circumstances. I personally don't really know, which > is why I'm asking. I did something very much like this with leafpad and notecase recently, except that I appended an "a" to the old tag to create the new one. I felt that changing anything else in the tag could possibly cause a collision in the future. Was it the correct thing to do? I'm not sure; it could come back and bite someone in the future. Was it the right thing to do? I feel so since bumping the package release due to a trivial slip-up would be silly. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bugs.michael at gmx.net Thu Aug 4 01:34:46 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 4 Aug 2005 03:34:46 +0200 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804002944.2ec16c74@python2> References: <20050804002944.2ec16c74@python2> Message-ID: <20050804033446.7793596c.bugs.michael@gmx.net> On Thu, 4 Aug 2005 00:29:44 +0200, Matthias Saou wrote: > I manually tagged the FC-3 branch where the patch was now included as > *-1_1_fc3 (where it previously was *-1_fc3) without actually changing the > release nor anything else in the spec file, and asked plague to rebuild > that new branch. This is not really "abuse", since you created a new tag. It is somewhat confusing use of a tag, since somebody who wanted to check out the *-1_fc3 revision, would get the package with the missing files. Moving the tag could be called "abuse" under certain circumstances. From tmraz at redhat.com Thu Aug 4 08:38:51 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 04 Aug 2005 10:38:51 +0200 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804002944.2ec16c74@python2> References: <20050804002944.2ec16c74@python2> Message-ID: <1123144732.5315.6.camel@perun.redhat.usu> On Thu, 2005-08-04 at 00:29 +0200, Matthias Saou wrote: > Hi, > > Well, the subject is maybe a bit alarming, don't worry just yet :-) > I wanted to get some maintainer's opinion about what I just did, which > doesn't bother me much, but might be something for which consensus ends up > being "don't do that, ever!" : > > I had forgot to commit a patch into CVS for synergy's FC-3 branch, and > just committed the exact same files (except for that missing patch) to all > FC-3, FC-4 and devel branches, tagged them and requested builds. > Obviously, the FC-3 build immediately failed upon trying to build the > source rpm, whereas the two others were going to build fine. > > The typical thing to do here would have been to bump the release and ask > for a new build. But that would have meant bump the FC-4 and devel > releases too to keep them in order (since I used "1%{?dist}" for all > three), for nothing... so I tried something else. > > I manually tagged the FC-3 branch where the patch was now included as > *-1_1_fc3 (where it previously was *-1_fc3) without actually changing the > release nor anything else in the spec file, and asked plague to rebuild > that new branch. ... IMHO, you should have done instead 'TAG_OPTS=-F make tag' of course IF and ONLY IF the build failed. The tag in CVS should indicate that a the rpm with the same NVR as in the TAG was created from this exact CVS contents. So moving the tag if no such rpm was created yet should be perfectly correct. On the other hand what you have done is really confusing because the *-1_fc3 tag doesn't reflect the state as of -1.fc3 rpm (this is a big problem) and for the *-1_1_fc3 tag doesn't exist a -1.1.fc3 rpm (this is not a problem). -- Tomas Mraz From ville.skytta at iki.fi Thu Aug 4 08:53:02 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 04 Aug 2005 11:53:02 +0300 Subject: My first (ab)use of the CVS tags In-Reply-To: <1123144732.5315.6.camel@perun.redhat.usu> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> Message-ID: <1123145582.3005.77.camel@localhost.localdomain> On Thu, 2005-08-04 at 10:38 +0200, Tomas Mraz wrote: > On Thu, 2005-08-04 at 00:29 +0200, Matthias Saou wrote: > > > I manually tagged the FC-3 branch where the patch was now included as > > *-1_1_fc3 (where it previously was *-1_fc3) without actually changing the > > release nor anything else in the spec file, and asked plague to rebuild > > that new branch. > ... > > IMHO, you should have done instead 'TAG_OPTS=-F make tag' of course IF > and ONLY IF the build failed. The tag in CVS should indicate that a the > rpm with the same NVR as in the TAG was created from this exact CVS > contents. > > So moving the tag if no such rpm was created yet should be perfectly > correct. On the other hand what you have done is really confusing > because the *-1_fc3 tag doesn't reflect the state as of -1.fc3 rpm (this > is a big problem) and for the *-1_1_fc3 tag doesn't exist a -1.1.fc3 rpm > (this is not a problem). Just appending something, eg. ".1", to the release tag in the affected branch and tagging and building as usual would have worked, too. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Aug 4 10:57:27 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 4 Aug 2005 12:57:27 +0200 Subject: My first (ab)use of the CVS tags In-Reply-To: <1123145582.3005.77.camel@localhost.localdomain> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> <1123145582.3005.77.camel@localhost.localdomain> Message-ID: <20050804125727.2c0c33e6@python2> Ville Skytt? wrote : > On Thu, 2005-08-04 at 10:38 +0200, Tomas Mraz wrote: > > On Thu, 2005-08-04 at 00:29 +0200, Matthias Saou wrote: > > > > > I manually tagged the FC-3 branch where the patch was now included as > > > *-1_1_fc3 (where it previously was *-1_fc3) without actually changing the > > > release nor anything else in the spec file, and asked plague to rebuild > > > that new branch. > > ... > > > > IMHO, you should have done instead 'TAG_OPTS=-F make tag' of course IF > > and ONLY IF the build failed. The tag in CVS should indicate that a the > > rpm with the same NVR as in the TAG was created from this exact CVS > > contents. This is interesting : One can force a tag to be overwritten? I had no idea that could be achieved, and does seem like the proper way of doing things if no package has yet been built from the current tag. Thoughts? > > So moving the tag if no such rpm was created yet should be perfectly > > correct. On the other hand what you have done is really confusing > > because the *-1_fc3 tag doesn't reflect the state as of -1.fc3 rpm (this > > is a big problem) and for the *-1_1_fc3 tag doesn't exist a -1.1.fc3 rpm > > (this is not a problem). > > Just appending something, eg. ".1", to the release tag in the affected > branch and tagging and building as usual would have worked, too. So 1.1.fc3 < 1.fc4? I've been bitten too many times to be able to swear that's correct without checking it first ;-) Also, since no "1.fc3" package had been built, it doesn't make that much sense to bump the release for the build. I personally prefer the suggestion above of overwriting the tag, as long as it's used with extreme caution... And I now realize that what I did is plain wrong, since as Michael pointed out, someone wanting to check out the CVS files for the "1.fc3" package will use the tag where the patch is missing. So I definitely won't do it again ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.09 0.13 0.14 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Aug 4 11:21:13 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 4 Aug 2005 13:21:13 +0200 Subject: Package needing to be shared across multiple branches Message-ID: <20050804132113.05a16ff0@python2> Hi, I've just rebuilt some packages for torcs and torcs-data (The Open Racing Car Simulator) for development, which fix some problems that had been reported. My concern now is that the source torcs-data package is 65MB in size, with the resulting noarch packages occupying the same, and those are completely arch and distro independant. So I'd like to find a way to have the torcs-data packages I've just released in development hardlinked to the FC-3 and FC-4 trees since it will save a few hundred megabytes on all Fedora Extras mirrors. Can I just request that on the FC3Status and FC4Status Wiki pages? Will there be a formal process for this case, since it's definitely not an isolated one? Would be nice... but probably won't be easy, though. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.12 0.19 0.22 From tmraz at redhat.com Thu Aug 4 11:40:05 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 04 Aug 2005 13:40:05 +0200 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804125727.2c0c33e6@python2> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> <1123145582.3005.77.camel@localhost.localdomain> <20050804125727.2c0c33e6@python2> Message-ID: <1123155605.5315.13.camel@perun.redhat.usu> On Thu, 2005-08-04 at 12:57 +0200, Matthias Saou wrote: > Ville Skytt? wrote : > > > On Thu, 2005-08-04 at 10:38 +0200, Tomas Mraz wrote: > > > On Thu, 2005-08-04 at 00:29 +0200, Matthias Saou wrote: > > > > > > > I manually tagged the FC-3 branch where the patch was now included as > > > > *-1_1_fc3 (where it previously was *-1_fc3) without actually changing the > > > > release nor anything else in the spec file, and asked plague to rebuild > > > > that new branch. > > > ... > > > > > > IMHO, you should have done instead 'TAG_OPTS=-F make tag' of course IF > > > and ONLY IF the build failed. The tag in CVS should indicate that a the > > > rpm with the same NVR as in the TAG was created from this exact CVS > > > contents. > > This is interesting : One can force a tag to be overwritten? I had no idea > that could be achieved, and does seem like the proper way of doing things > if no package has yet been built from the current tag. Thoughts? We do it in case of build failure regularly in the Core CVS - there is even a make force-tag target. > So 1.1.fc3 < 1.fc4? I've been bitten too many times to be able to swear > that's correct without checking it first ;-) Also, since no "1.fc3" > package had been built, it doesn't make that much sense to bump the > release for the build. I personally prefer the suggestion above of > overwriting the tag, as long as it's used with extreme caution... 1.1.fc3 > 1.fc4 because numeric parts are considered > than alphabetic. > And I now realize that what I did is plain wrong, since as Michael pointed > out, someone wanting to check out the CVS files for the "1.fc3" package > will use the tag where the patch is missing. So I definitely won't do it > again ;-) Good. ;-) -- Tomas Mraz From ville.skytta at iki.fi Thu Aug 4 14:47:58 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 04 Aug 2005 17:47:58 +0300 Subject: My first (ab)use of the CVS tags In-Reply-To: <1123155605.5315.13.camel@perun.redhat.usu> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> <1123145582.3005.77.camel@localhost.localdomain> <20050804125727.2c0c33e6@python2> <1123155605.5315.13.camel@perun.redhat.usu> Message-ID: <1123166878.3005.88.camel@localhost.localdomain> On Thu, 2005-08-04 at 13:40 +0200, Tomas Mraz wrote: > On Thu, 2005-08-04 at 12:57 +0200, Matthias Saou wrote: > > So 1.1.fc3 < 1.fc4? I've been bitten too many times to be able to swear > > that's correct without checking it first ;-) Also, since no "1.fc3" > > package had been built, it doesn't make that much sense to bump the > > release for the build. I personally prefer the suggestion above of > > overwriting the tag, as long as it's used with extreme caution... > > 1.1.fc3 > 1.fc4 because numeric parts are considered > than alphabetic. Yes, but I said "appending". 1.fc3.1 < 1.fc4. From fedora at camperquake.de Thu Aug 4 14:50:06 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 4 Aug 2005 16:50:06 +0200 Subject: My first (ab)use of the CVS tags In-Reply-To: <1123166878.3005.88.camel@localhost.localdomain> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> <1123145582.3005.77.camel@localhost.localdomain> <20050804125727.2c0c33e6@python2> <1123155605.5315.13.camel@perun.redhat.usu> <1123166878.3005.88.camel@localhost.localdomain> Message-ID: <20050804165006.18d35e33@nausicaa.camperquake.de> Hi. Ville Skytt? wrote: > Yes, but I said "appending". 1.fc3.1 < 1.fc4. Uah. I do not think I like that idea. -- Q. In Malta, on which side of the road do they drive? A. The shady side. From ville.skytta at iki.fi Thu Aug 4 15:10:52 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 04 Aug 2005 18:10:52 +0300 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804165006.18d35e33@nausicaa.camperquake.de> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> <1123145582.3005.77.camel@localhost.localdomain> <20050804125727.2c0c33e6@python2> <1123155605.5315.13.camel@perun.redhat.usu> <1123166878.3005.88.camel@localhost.localdomain> <20050804165006.18d35e33@nausicaa.camperquake.de> Message-ID: <1123168252.3005.110.camel@localhost.localdomain> On Thu, 2005-08-04 at 16:50 +0200, Ralf Ertzinger wrote: > Hi. > > Ville Skytt? wrote: > > > Yes, but I said "appending". 1.fc3.1 < 1.fc4. > > Uah. I do not think I like that idea. Shrug, it's dead simple, works, and the trailing part can be pruned in the next package revision if someone doesn't like it. See also "rpm -qa | grep -i fc4." From ville.skytta at iki.fi Thu Aug 4 15:12:46 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 04 Aug 2005 18:12:46 +0300 Subject: Package needing to be shared across multiple branches In-Reply-To: <20050804132113.05a16ff0@python2> References: <20050804132113.05a16ff0@python2> Message-ID: <1123168366.3005.113.camel@localhost.localdomain> On Thu, 2005-08-04 at 13:21 +0200, Matthias Saou wrote: > I've just rebuilt some packages for torcs and torcs-data (The Open Racing > Car Simulator) for development, which fix some problems that had been > reported. My concern now is that the source torcs-data package is 65MB in > size, with the resulting noarch packages occupying the same, and those are > completely arch and distro independant. I've been asking that a couple of times earlier, too. > So I'd like to find a way to have the torcs-data packages I've just > released in development hardlinked to the FC-3 and FC-4 trees since it > will save a few hundred megabytes on all Fedora Extras mirrors. Can I just > request that on the FC3Status and FC4Status Wiki pages? As far as I'm concerned, yes. Opinions welcome whether there's value in having them hardlinked in the "root" Extras repository on fedoraproject.org or if a "cp -p" would be enough/better. > Will there be a formal process for this case, since it's definitely not an > isolated one? Would be nice... but probably won't be easy, though. I don't really see anything that wouldn't be easy about it, and yes, I volunteer to help with these copy requests. Unless someone violently objects to the whole idea of hardlinking/copying or has better ideas, let's use the FC[34]Status pages for this for now. From bugs.michael at gmx.net Thu Aug 4 15:21:42 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 4 Aug 2005 17:21:42 +0200 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804165006.18d35e33@nausicaa.camperquake.de> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> <1123145582.3005.77.camel@localhost.localdomain> <20050804125727.2c0c33e6@python2> <1123155605.5315.13.camel@perun.redhat.usu> <1123166878.3005.88.camel@localhost.localdomain> <20050804165006.18d35e33@nausicaa.camperquake.de> Message-ID: <20050804172142.49c5aaf5.bugs.michael@gmx.net> On Thu, 4 Aug 2005 16:50:06 +0200, Ralf Ertzinger wrote: > Ville Skytt? wrote: > > > Yes, but I said "appending". 1.fc3.1 < 1.fc4. > > Uah. I do not think I like that idea. Your rationale being what? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Aug 4 15:31:13 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 4 Aug 2005 17:31:13 +0200 Subject: Package needing to be shared across multiple branches In-Reply-To: <1123168366.3005.113.camel@localhost.localdomain> References: <20050804132113.05a16ff0@python2> <1123168366.3005.113.camel@localhost.localdomain> Message-ID: <20050804173113.0693585b@python2> Ville Skytt? wrote : > > So I'd like to find a way to have the torcs-data packages I've just > > released in development hardlinked to the FC-3 and FC-4 trees since it > > will save a few hundred megabytes on all Fedora Extras mirrors. Can I just > > request that on the FC3Status and FC4Status Wiki pages? > > As far as I'm concerned, yes. Opinions welcome whether there's value in > having them hardlinked in the "root" Extras repository on > fedoraproject.org or if a "cp -p" would be enough/better. Well, if you're going to run "cp", you might as well use "-l" too in order to hardlink the files on the master server :-) > > Will there be a formal process for this case, since it's definitely not an > > isolated one? Would be nice... but probably won't be easy, though. > > I don't really see anything that wouldn't be easy about it, and yes, I > volunteer to help with these copy requests. Unless someone violently > objects to the whole idea of hardlinking/copying or has better ideas, > let's use the FC[34]Status pages for this for now. I'd definitely be willing to help too, and don't object to those manual hardlinking operations in any way. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 0.40 0.26 0.25 From ville.skytta at iki.fi Thu Aug 4 16:18:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 04 Aug 2005 19:18:04 +0300 Subject: Package needing to be shared across multiple branches In-Reply-To: <20050804173113.0693585b@python2> References: <20050804132113.05a16ff0@python2> <1123168366.3005.113.camel@localhost.localdomain> <20050804173113.0693585b@python2> Message-ID: <1123172284.3005.118.camel@localhost.localdomain> On Thu, 2005-08-04 at 17:31 +0200, Matthias Saou wrote: > Well, if you're going to run "cp", you might as well use "-l" too in order > to hardlink the files on the master server :-) Sure, but it's a matter of rsync's behaviour with hardlinks, which according to the man page is slow/expensive. I've no first hand experience on this nor can I tell whether it'd matter on the fedoraproject.org servers. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Aug 4 16:35:42 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 4 Aug 2005 18:35:42 +0200 Subject: Package needing to be shared across multiple branches In-Reply-To: <1123172284.3005.118.camel@localhost.localdomain> References: <20050804132113.05a16ff0@python2> <1123168366.3005.113.camel@localhost.localdomain> <20050804173113.0693585b@python2> <1123172284.3005.118.camel@localhost.localdomain> Message-ID: <20050804183542.6ffd5576@python2> Ville Skytt? wrote : > On Thu, 2005-08-04 at 17:31 +0200, Matthias Saou wrote: > > > Well, if you're going to run "cp", you might as well use "-l" too in order > > to hardlink the files on the master server :-) > > Sure, but it's a matter of rsync's behaviour with hardlinks, which > according to the man page is slow/expensive. I've no first hand > experience on this nor can I tell whether it'd matter on the > fedoraproject.org servers. All mirror admins I know use rsync -H already (preserve hardlinks), or at least run "hardlink" or "hardlink++" locally after syncing. Even on trees as big as /pub/redhat or /pub/fedora, it's not _too_ expensive (but of course, this is subjective) and really saves a non negligible amount of disk space. For my /pub/fedora (core+extras) : Hard linking Statistics: Directories : 269 Regular files : 85471 Comparisons : 139 Hardlinked this run : 0 Total hardlinks : 19659 Bytes saved this run : 0 Total gibibytes saved : 14.6671 Total mibibytes saved : 15019.1 Total kibibytes saved : 1.53796e+07 Total bytes saved : 15748679984 Many of those are noarch packages, but also all of the i386 ones in x86_64, etc. My "partial" mirror : $ du -sh /var/ftp/pub/fedora 76G fedora So without all the existing hardlinks, it would use up roughly 90GB instead, which is roughly a 20% increase. So hardlinks where possible are a good thing IMHO, even if it would be easiest to just throw everything at the build system. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4 Load : 1.49 1.98 1.47 From wtogami at redhat.com Thu Aug 4 23:06:37 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 04 Aug 2005 13:06:37 -1000 Subject: Package needing to be shared across multiple branches In-Reply-To: <20050804132113.05a16ff0@python2> References: <20050804132113.05a16ff0@python2> Message-ID: <42F29F7D.5080608@redhat.com> My opinion is that cases where you *KNOW* a package can be the same across multiple distributions, build one without a dist tag and note it in those Wiki pages. Either me, Ville or Michael can hardlink it across the distributions during the next Extras push. This is especially important for larger packages, like this 65MB thing you mention. Warren Togami wtogami at redhat.com From dcbw at redhat.com Fri Aug 5 16:43:59 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 05 Aug 2005 12:43:59 -0400 Subject: Build system questions In-Reply-To: <20050803172221.3e88bb02@python2> References: <20050803172221.3e88bb02@python2> Message-ID: <1123260239.4789.12.camel@dcbw.boston.redhat.com> On Wed, 2005-08-03 at 17:22 +0200, Matthias Saou wrote: > Hi, > > - Would it be possible to have plague-client display the job id assigned > to the job that just got submitted? That would make things really easier > to check the status of the job from there, without having to hunt for the > job first. Should be fixed in CVS. The Job ID may not always get returned if the server is under heavy load, as the job gets inserted into the database in a separate thread, and the XMLRPC code will only wait for 3 seconds for that thread to return the Job ID before giving up. We can tweak that timeout if needed. Dan From skvidal at phy.duke.edu Sat Aug 6 07:33:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 06 Aug 2005 03:33:41 -0400 Subject: buildsystem status Message-ID: <1123313621.27510.25.camel@cutter> Hi everyone, I cleaned out the successful build results from the db and I also removed the failed builds that were older than a certain range. I didn't remove the data from the system, you can still see the failed build logs at the same url they just are no longer in the db so they won't show up in a plague-client list or on the web page. I made a backup of the database so if there is any data in there that is absolutely critical let me know and I'll see if I can find it. Thanks, -sv From aoliva at redhat.com Sun Aug 7 21:20:55 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 07 Aug 2005 18:20:55 -0300 Subject: My first (ab)use of the CVS tags In-Reply-To: <20050804125727.2c0c33e6@python2> References: <20050804002944.2ec16c74@python2> <1123144732.5315.6.camel@perun.redhat.usu> <1123145582.3005.77.camel@localhost.localdomain> <20050804125727.2c0c33e6@python2> Message-ID: On Aug 4, 2005, Matthias Saou wrote: > And I now realize that what I did is plain wrong, since as Michael pointed > out, someone wanting to check out the CVS files for the "1.fc3" package > will use the tag where the patch is missing. So I definitely won't do it > again ;-) And now that you know you can fix tags, you may go ahead and fix the 1.fc3 tag such that it matches what was actually built :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Fri Aug 12 01:50:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 11 Aug 2005 21:50:50 -0400 Subject: buildsystem status report Message-ID: <1123811450.12234.6.camel@cutter> Hey Folks, Just a quick update. Dan has committed a lot of fixes and a lot of patches to the buildsys and on monday we're going to switch over to a newer version. We're not yet sure on the various details but this is where we are right now. There's a good chance that in order to use this update to the buildsys code we're going to have to get everyone using 'make plague' or 'plague-client' directly to update their version of plague-client after we update the buildsys server code. We'll let you know more as we know it. Thanks, -sv From dcbw at redhat.com Fri Aug 12 04:49:17 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 12 Aug 2005 00:49:17 -0400 (EDT) Subject: buildsystem status report In-Reply-To: <1123811450.12234.6.camel@cutter> References: <1123811450.12234.6.camel@cutter> Message-ID: On Thu, 11 Aug 2005, seth vidal wrote: > Hey Folks, > Just a quick update. > > Dan has committed a lot of fixes and a lot of patches to the buildsys > and on monday we're going to switch over to a newer version. We're not > yet sure on the various details but this is where we are right now. > > There's a good chance that in order to use this update to the buildsys > code we're going to have to get everyone using 'make plague' or > 'plague-client' directly to update their version of plague-client after > we update the buildsys server code. Yes, anyone using 'make plague' or 'plague-client' will need to grab the current Extras packages (0.3 or higher). Between 0.2 and 0.3 the API has changed slightly. I believe that people will still be able to queue packages but will get an error back instead of the job ID. Other commands will not work as well. In any case, people will know that it's not working :) To protect against this in the future, perhaps some sort of API versioning could be implemented, or at least have the client check the server's version and refuse to talk to the server unless the .x matches. Or something. Dan From bugs.michael at gmx.net Fri Aug 12 08:15:41 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 12 Aug 2005 10:15:41 +0200 Subject: buildsystem status report In-Reply-To: References: <1123811450.12234.6.camel@cutter> Message-ID: <20050812101541.3a3f5bf4.bugs.michael@gmx.net> On Fri, 12 Aug 2005 00:49:17 -0400 (EDT), Dan Williams wrote: > Yes, anyone using 'make plague' or 'plague-client' will need to grab the current > Extras packages (0.3 or higher). As a matter of convenience, can those packages be made available in Fedora Extras 3 and 4, too, so a simple "yum update" gets them? From dcbw at redhat.com Mon Aug 15 19:05:20 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 Aug 2005 15:05:20 -0400 Subject: [UPGRADE COMPLETE] Re: Extras build system upgrade notice In-Reply-To: References: Message-ID: <1124132720.3145.11.camel@dcbw.boston.redhat.com> On Mon, 2005-08-15 at 08:15 -0400, Dan Williams wrote: > Hi, > > Seth, Jeremy, and I are upgrading the Extras build system today. We'll send out > the announcement when the upgrade is complete, which is likely to take until > late Monday afternoon, US EST, to get all the pieces together. The build system should be back up and accepting build jobs. You'll have to have plague-0.3.2-1 or later to talk to the build server. Rawhide RPMs are built already, I'll get some RPMs built for FC3 and FC4 here in a bit. Dan From krh at redhat.com Tue Aug 16 00:12:10 2005 From: krh at redhat.com (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=) Date: Mon, 15 Aug 2005 20:12:10 -0400 Subject: Rebuild of gtk+ dependent packages required Message-ID: <43012F5A.4090104@redhat.com> Hi, So, ugh, the cairo soname got bumped with the new 0.9.2 releaese. From the release note: In all prior snapshots, the libtool library versioning was set to 1:0:0. As this release is intended to mark the beginning of backwards-compatible releases, the versioning has been incremented to 2:0:0. You will notice that the numeric extension on the installed library filename will change similarly. This change will also require all cairo-using applications to be recompiled. We recognize that this may cause some frustration since this release is backwards-compatible with 0.6.0 and in that sense "shouldn't" require re-compilation. However, since all historical snapshots have used the same 1:0:0 version in spite of incompatible API changes between them, it was essential that the upcoming 1.0 release series have distinct library versioning. This means that anything linking to cairo, which include anything linking to gtk+, needs to be rebuilt. Pango and gtk+ have been rebuilt, and now it's just the other 110 packages. I've attached the list of packages in question as reported by rpm -qp --requires, please rebuild your packages. thanks, Kristian -------------- next part -------------- A non-text attachment was scrubbed... Name: packages.txt Type: text/x-diff Size: 3204 bytes Desc: not available URL: From twaugh at redhat.com Tue Aug 16 16:46:50 2005 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 16 Aug 2005 17:46:50 +0100 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43012F5A.4090104@redhat.com> References: <43012F5A.4090104@redhat.com> Message-ID: <20050816164650.GV7718@redhat.com> On Mon, Aug 15, 2005 at 08:12:10PM -0400, Kristian H?gsberg wrote: > This means that anything linking to cairo, which include anything > linking to gtk+, needs to be rebuilt. Pango and gtk+ have been rebuilt, > and now it's just the other 110 packages. I've attached the list of > packages in question as reported by rpm -qp --requires, please rebuild > your packages. I've rebuilt ghostscript and gimp-print. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Tue Aug 16 19:25:16 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 16 Aug 2005 15:25:16 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43012F5A.4090104@redhat.com> References: <43012F5A.4090104@redhat.com> Message-ID: <1124220316.20459.5.camel@cassandra.boston.redhat.com> On Mon, 2005-08-15 at 20:12 -0400, Kristian H?gsberg wrote: > Hi, > > So, ugh, the cairo soname got bumped with the new 0.9.2 releaese. From > the release note: > > In all prior snapshots, the libtool library versioning was set to > 1:0:0. As this release is intended to mark the beginning of > backwards-compatible releases, the versioning has been incremented > to 2:0:0. You will notice that the numeric extension on the > installed library filename will change similarly. > > This change will also require all cairo-using applications to be > recompiled. We recognize that this may cause some frustration since > this release is backwards-compatible with 0.6.0 and in that sense > "shouldn't" require re-compilation. However, since all historical > snapshots have used the same 1:0:0 version in spite of incompatible > API changes between them, it was essential that the upcoming 1.0 > release series have distinct library versioning. > > This means that anything linking to cairo, which include anything > linking to gtk+, needs to be rebuilt. Pango and gtk+ have been rebuilt, > and now it's just the other 110 packages. I've attached the list of > packages in question as reported by rpm -qp --requires, please rebuild > your packages. I've rebuilt: gtkhtml3 evolution-data-server evolution-connector evolution-webcal gnome-pilot and am working on evolution. The code in libgal2 has been either moved to evolution, or taken out and shot, so I'm marking that as obsoleted in the latest evolution package. Jeremy can do the final purge, since I know he likes this kind of thing :-) Dave From fedora at camperquake.de Tue Aug 16 21:45:55 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 16 Aug 2005 23:45:55 +0200 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43012F5A.4090104@redhat.com> References: <43012F5A.4090104@redhat.com> Message-ID: <20050816234555.3cd4ff57@nausicaa.camperquake.de> Hi. Kristian H?gsberg wrote: > This means that anything linking to cairo, which include anything > linking to gtk+, needs to be rebuilt. Eh, sure? I have a package in FE-devel (bmp) which links GTK+, but does not explicitly require cairo. -- "Someone educate this boy before he amazes us to death." -- Andy Loan, re Tim Down From nalin at redhat.com Tue Aug 16 22:12:02 2005 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 16 Aug 2005 18:12:02 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <20050816234555.3cd4ff57@nausicaa.camperquake.de> References: <43012F5A.4090104@redhat.com> <20050816234555.3cd4ff57@nausicaa.camperquake.de> Message-ID: <20050816221202.GC11729@redhat.com> On Tue, Aug 16, 2005 at 11:45:55PM +0200, Ralf Ertzinger wrote: > Hi. > > Kristian H?gsberg wrote: > > > This means that anything linking to cairo, which include anything > > linking to gtk+, needs to be rebuilt. > > Eh, sure? I have a package in FE-devel (bmp) which links GTK+, but > does not explicitly require cairo. The "bmp" package doesn't list libcairo.so.1 as a dependency, so it appears that you don't need a rebuild for this. The yum-utils package lets you do this: repoquery --repoid=extras-development --whatrequires libcairo.so.1 to get a list of which Extras packages now have broken deps (sorted): abiword - 1:2.2.9-1.i386 aiksaurus-gtk - 1:1.2.1-9.i386 airsnort - 0.2.7e-5.fc5.i386 anjuta - 1:1.2.3-2.fc5.i386 at-poke - 0.2.2-2.i386 bluefish - 1.0.2-1.fc5.i386 bluefish - 1.0.2-2.fc5.i386 brightside - 1.4.0-8.i386 contact-lookup-applet - 0.13-2.fc5.i386 exo - 0.3.0-9.fc5.i386 exo-devel - 0.3.0-9.fc5.i386 firestarter - 1.0.3-5.fc5.i386 freeciv - 2.0.3-2.fc5.i386 freeciv - 2.0.4-2.fc5.i386 fyre - 1.0.0-9.fc5.i386 gai - 0.5.10-3.fc5.i386 gaim-guifications - 2.12-1.fc5.i386 gai-temp - 0.1.1-2.fc5.i386 galculator - 1.2.5-1.fc5.i386 gkrellm-aclock - 0.3.3-1.fc5.i386 glabels - 2.0.3-2.fc5.i386 glunarclock - 0.32.4-1.fc5.i386 glunarclock - 0.32.4-2.fc5.i386 gnome-applet-sensors - 1.0-2.fc5.i386 gnumeric - 1:1.4.3-5.i386 gossip - 0.9-3.fc5.i386 grip - 1:3.2.0-5.fc5.i386 grip - 1:3.2.0-6.fc5.i386 inkscape - 0.42-2.fc5.i386 istanbul - 0.1.1-4.i386 leafpad - 0.8.3-1.fc5.i386 libgnomedb - 1:1.2.0-4.i386 liferea - 0.9.3-1.fc5.i386 liferea - 0.9.4-2.fc5.i386 liferea - 0.9.5-2.fc5.i386 nautilus-open-terminal - 0.4-5.fc5.i386 NetworkManager-vpnc - 0.2-2.i386 plplot-gnome - 5.5.3-7.fc5.i386 python-matplotlib - 0.83.1-2.fc5.i386 python-matplotlib - 0.83.2-1.fc5.i386 revelation - 0.4.4-1.fc5.i386 scim - 1.3.3-1.fc5.i386 screem - 0.14.1-1.fc5.i386 seahorse - 0.7.9-1.fc5.i386 sylpheed - 2.0.0-0.2.beta3.i386 sylpheed - 2.0.0-0.4.beta4.i386 sylpheed - 2.0.0-0.4.beta6.i386 sylpheed - 2.0.0-1.i386 synaptic - 0.57.2-1.fc5.i386 Terminal - 0.2.4-3.i386 Terminal - 0.2.4-4.fc5.i386 uim-gnome - 0.4.6-4.i386 uim-gnome - 0.4.6-5.i386 uim-gnome - 0.4.7.1-1.fc5.i386 uim-gnome - 0.4.7.1-2.fc5.i386 uim-gnome - 0.4.7-1.fc5.i386 uim-gtk2 - 0.4.6-4.i386 uim-gtk2 - 0.4.6-5.i386 uim-gtk2 - 0.4.7.1-1.fc5.i386 uim-gtk2 - 0.4.7.1-2.fc5.i386 uim-gtk2 - 0.4.7-1.fc5.i386 HTH, Nalin From mclasen at redhat.com Tue Aug 16 22:17:23 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 16 Aug 2005 18:17:23 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <20050816234555.3cd4ff57@nausicaa.camperquake.de> References: <43012F5A.4090104@redhat.com> <20050816234555.3cd4ff57@nausicaa.camperquake.de> Message-ID: <1124230643.6388.18.camel@c-24-218-204-47.hsd1.ma.comcast.net> On Tue, 2005-08-16 at 23:45 +0200, Ralf Ertzinger wrote: > Hi. > > Kristian H?gsberg wrote: > > > This means that anything linking to cairo, which include anything > > linking to gtk+, needs to be rebuilt. > > Eh, sure? I have a package in FE-devel (bmp) which links GTK+, but > does not explicitly require cairo. > Maybe it hasn't been rebuilt since gtk+ added the cairo dependency ? From fedora at camperquake.de Tue Aug 16 22:26:59 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 17 Aug 2005 00:26:59 +0200 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <1124230643.6388.18.camel@c-24-218-204-47.hsd1.ma.comcast.net> References: <43012F5A.4090104@redhat.com> <20050816234555.3cd4ff57@nausicaa.camperquake.de> <1124230643.6388.18.camel@c-24-218-204-47.hsd1.ma.comcast.net> Message-ID: <20050817002659.70c6d07e@nausicaa.camperquake.de> Hi. Matthias Clasen wrote: > > Eh, sure? I have a package in FE-devel (bmp) which links GTK+, but > > does not explicitly require cairo. > > > > Maybe it hasn't been rebuilt since gtk+ added the cairo dependency ? This is probably the case. -- Leichen sind Menschen wie Du und ich, nur tot. From jspaleta at gmail.com Tue Aug 16 22:50:44 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 16 Aug 2005 18:50:44 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43012F5A.4090104@redhat.com> References: <43012F5A.4090104@redhat.com> Message-ID: <604aa79105081615502e64c9a1@mail.gmail.com> On 8/15/05, Kristian H?gsberg wrote: > This means that anything linking to cairo, which include anything > linking to gtk+, needs to be rebuilt. Pango and gtk+ have been rebuilt, > and now it's just the other 110 packages. I've attached the list of > packages in question as reported by rpm -qp --requires, please rebuild > your packages. Does this list cover everything in Fedora Extras development as well? What was the exact rpm -q command you used here.. I imagine we can duplicate it using repoquery and get a full accounting of affected packages in Core+Extras development trees. -jef From jspaleta at gmail.com Tue Aug 16 23:04:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 16 Aug 2005 19:04:36 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <604aa79105081615502e64c9a1@mail.gmail.com> References: <43012F5A.4090104@redhat.com> <604aa79105081615502e64c9a1@mail.gmail.com> Message-ID: <604aa7910508161604af53bdc@mail.gmail.com> On 8/16/05, Jeff Spaleta wrote: > Does this list cover everything in Fedora Extras development as well? To answer my own question.... 42 Extras packages.... need to be rebuilt... ain't that a kick in the head. repoquery -q --repoid=extras-development --whatrequires libcairo.so.1|sort -jef"sigh... and my 2 packages need to be rebuilt..time to learn how to use the new buildsystem tools for extras"spaleta Here's the list. abiword - 1:2.2.9-1.i386 aiksaurus-gtk - 1:1.2.1-9.i386 airsnort - 0.2.7e-5.fc5.i386 anjuta - 1:1.2.3-2.fc5.i386 at-poke - 0.2.2-2.i386 bluefish - 1.0.2-2.fc5.i386 brightside - 1.4.0-8.i386 contact-lookup-applet - 0.13-2.fc5.i386 exo - 0.3.0-9.fc5.i386 exo-devel - 0.3.0-9.fc5.i386 firestarter - 1.0.3-5.fc5.i386 freeciv - 2.0.4-2.fc5.i386 fyre - 1.0.0-9.fc5.i386 gai - 0.5.10-3.fc5.i386 gaim-guifications - 2.12-1.fc5.i386 gai-temp - 0.1.1-2.fc5.i386 galculator - 1.2.5-1.fc5.i386 gkrellm-aclock - 0.3.3-1.fc5.i386 glabels - 2.0.3-2.fc5.i386 glunarclock - 0.32.4-2.fc5.i386 gnome-applet-sensors - 1.0-2.fc5.i386 gnumeric - 1:1.4.3-5.i386 gossip - 0.9-3.fc5.i386 grip - 1:3.2.0-6.fc5.i386 inkscape - 0.42-2.fc5.i386 istanbul - 0.1.1-4.i386 leafpad - 0.8.3-1.fc5.i386 libgnomedb - 1:1.2.0-4.i386 liferea - 0.9.5-2.fc5.i386 nautilus-open-terminal - 0.4-5.fc5.i386 NetworkManager-vpnc - 0.2-2.i386 plplot-gnome - 5.5.3-7.fc5.i386 python-matplotlib - 0.83.2-1.fc5.i386 revelation - 0.4.4-1.fc5.i386 scim - 1.3.3-1.fc5.i386 screem - 0.14.1-1.fc5.i386 seahorse - 0.7.9-1.fc5.i386 sylpheed - 2.0.0-1.i386 synaptic - 0.57.2-1.fc5.i386 Terminal - 0.2.4-4.fc5.i386 uim-gnome - 0.4.7-1.fc5.i386 uim-gtk2 - 0.4.7-1.fc5.i386 From bugs.michael at gmx.net Wed Aug 17 01:08:52 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 17 Aug 2005 03:08:52 +0200 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <604aa7910508161604af53bdc@mail.gmail.com> References: <43012F5A.4090104@redhat.com> <604aa79105081615502e64c9a1@mail.gmail.com> <604aa7910508161604af53bdc@mail.gmail.com> Message-ID: <20050817030852.1d2dfffa.bugs.michael@gmx.net> On Tue, 16 Aug 2005 19:04:36 -0400, Jeff Spaleta wrote: > To answer my own question.... > 42 Extras packages.... > need to be rebuilt... > ain't that a kick in the head. Most likely several of them will need to wait for some Core rebuilds first. Else something like this will happen: Error: Missing Dependency: libcairo.so.1 is needed by package libgnomeui Error: Missing Dependency: libcairo.so.1 is needed by package gnome-panel Error: Missing Dependency: libcairo.so.1 is needed by package libbonoboui-devel Error: Missing Dependency: libcairo.so.1 is needed by package gnome-keyring Error: Missing Dependency: libcairo.so.1 is needed by package GConf2 Error: Missing Dependency: libcairo.so.1 is needed by package gnome-desktop Error: Missing Dependency: libcairo.so.1 is needed by package libgnomecanvas Error: Missing Dependency: libcairo.so.1 is needed by package libwnck Error: Missing Dependency: libcairo.so.1 is needed by package libbonoboui http://buildsys.fedoraproject.org/logs//development/60-gai-0.5.10-4.fc5/i386/root.log [A good opportunity to use plague-client's "requeue" command when those deps are ready.] From j.w.r.degoede at hhs.nl Wed Aug 17 06:25:14 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 17 Aug 2005 08:25:14 +0200 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <20050817030852.1d2dfffa.bugs.michael@gmx.net> References: <43012F5A.4090104@redhat.com> <604aa79105081615502e64c9a1@mail.gmail.com> <604aa7910508161604af53bdc@mail.gmail.com> <20050817030852.1d2dfffa.bugs.michael@gmx.net> Message-ID: <4302D84A.7010105@hhs.nl> Michael Schwendt wrote: > On Tue, 16 Aug 2005 19:04:36 -0400, Jeff Spaleta wrote: > > >>To answer my own question.... >>42 Extras packages.... >>need to be rebuilt... >>ain't that a kick in the head. > > > Most likely several of them will need to wait for some Core rebuilds > first. Else something like this will happen: > > Error: Missing Dependency: libcairo.so.1 is needed by package libgnomeui > Error: Missing Dependency: libcairo.so.1 is needed by package gnome-panel > Error: Missing Dependency: libcairo.so.1 is needed by package libbonoboui-devel > Error: Missing Dependency: libcairo.so.1 is needed by package gnome-keyring > Error: Missing Dependency: libcairo.so.1 is needed by package GConf2 > Error: Missing Dependency: libcairo.so.1 is needed by package gnome-desktop > Error: Missing Dependency: libcairo.so.1 is needed by package libgnomecanvas > Error: Missing Dependency: libcairo.so.1 is needed by package libwnck > Error: Missing Dependency: libcairo.so.1 is needed by package libbonoboui > > http://buildsys.fedoraproject.org/logs//development/60-gai-0.5.10-4.fc5/i386/root.log > > [A good opportunity to use plague-client's "requeue" command when those > deps are ready.] > What's the difference between a reque and just requesting a new build? Regards, Hans From petersen at redhat.com Wed Aug 17 09:36:24 2005 From: petersen at redhat.com (Jens Petersen) Date: Wed, 17 Aug 2005 18:36:24 +0900 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43012F5A.4090104@redhat.com> References: <43012F5A.4090104@redhat.com> Message-ID: <43030518.5080100@redhat.com> Kristian H?gsberg wrote: > scim-1.4.1-1.i386.rpm > scim-anthy-0.5.3-6.i386.rpm > scim-hangul-0.2.0-3.fc5.i386.rpm > scim-pinyin-0.5.0-5.i386.rpm > scim-tables-0.5.1-4.i386.rpm These have all been updated or rebuilt. Jens From wtogami at redhat.com Wed Aug 17 09:49:43 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 16 Aug 2005 23:49:43 -1000 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43012F5A.4090104@redhat.com> References: <43012F5A.4090104@redhat.com> Message-ID: <43030837.9000402@redhat.com> I rebuilt a great many of these packages in the past few hours in an attempt to make tomorrow's rawhide less broken. I succeeded in most of rstrode's packages, but failed with gnome-applets. It appears that something else in the buildroot is still linked to the old cairo. /mnt/redhat/beehive/logs/gnome-applets-603630-x86_64-crowe.devel.redhat.com.log I might have missed other GNOME related packages. Warren Togami wtogami at redhat.com From bugs.michael at gmx.net Wed Aug 17 12:31:22 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 17 Aug 2005 14:31:22 +0200 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <4302D84A.7010105@hhs.nl> References: <43012F5A.4090104@redhat.com> <604aa79105081615502e64c9a1@mail.gmail.com> <604aa7910508161604af53bdc@mail.gmail.com> <20050817030852.1d2dfffa.bugs.michael@gmx.net> <4302D84A.7010105@hhs.nl> Message-ID: <20050817143122.2c519db5.bugs.michael@gmx.net> On Wed, 17 Aug 2005 08:25:14 +0200, Hans de Goede wrote: > What's the difference between a reque and just requesting a new build? Order of build requests may be important. And a requeue doesn't need access to a cvs tag. Job# is enough. From rstrode at redhat.com Wed Aug 17 13:27:57 2005 From: rstrode at redhat.com (Ray Strode) Date: Wed, 17 Aug 2005 09:27:57 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43030837.9000402@redhat.com> References: <43012F5A.4090104@redhat.com> <43030837.9000402@redhat.com> Message-ID: <1124285277.12040.0.camel@localhost.localdomain> Hi, > I rebuilt a great many of these packages in the past few hours in an > attempt to make tomorrow's rawhide less broken. I succeeded in most of > rstrode's packages, Thanks! --Ray From jspaleta at gmail.com Thu Aug 18 21:22:58 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 18 Aug 2005 17:22:58 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <43012F5A.4090104@redhat.com> References: <43012F5A.4090104@redhat.com> Message-ID: <604aa79105081814222d78f31b@mail.gmail.com> On 8/15/05, Kristian H?gsberg wrote: > This means that anything linking to cairo, which include anything > linking to gtk+, needs to be rebuilt. Pango and gtk+ have been rebuilt, > and now it's just the other 110 packages. I've attached the list of > packages in question as reported by rpm -qp --requires, please rebuild > your packages. Okay it looks like all the Core packages are cleaned up. Lets see if I can get my 2 Extras packages rebuilt against rawhide in mock and then get a build request out this evening. -jef From kwade at redhat.com Fri Aug 19 01:38:05 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 18 Aug 2005 18:38:05 -0700 Subject: ref. beat writers post on f-devel-l Message-ID: <1124415485.916.79.camel@erato.phig.org> I didn't want to cross-post, but I want to call your attention to this thread on f-devel-l: http://www.redhat.com/archives/fedora-devel-list/2005-August/msg00329.html It is vital for us to identify writers for the release notes beats. You all are the best pool to steer people in this direction. Think of it as your way to seed the quality of what is written about your area of the distro. :) I need you to: a) recruit writers for beats b) get other developers to do the same Help us keep this alive. BTW, if we do this correctly, we'll have a translated release note draft for test1. The real thing. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- 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 Sat Aug 20 12:14:30 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 20 Aug 2005 14:14:30 +0200 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <604aa79105081814222d78f31b@mail.gmail.com> References: <43012F5A.4090104@redhat.com> <604aa79105081814222d78f31b@mail.gmail.com> Message-ID: <20050820141430.623b92cb.bugs.michael@gmx.net> On Thu, 18 Aug 2005 17:22:58 -0400, Jeff Spaleta wrote: > Okay it looks like all the Core packages are cleaned up. Is it intentional, that redhat-artwork-0.126-1 still references libcairo.so.1? $ userinfo (userinfo:3304): Gtk-WARNING **: libcairo.so.1: cannot open shared object file: No such file or directory $ ldd /usr/lib/gtk-2.0/2.4.0/engines/libbluecurve.so | grep cairo libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00118000) libcairo.so.1 => not found libcairo.so.2 => /usr/lib/libcairo.so.2 (0x0021e000) From jspaleta at gmail.com Sat Aug 20 12:33:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 20 Aug 2005 08:33:04 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <20050820141430.623b92cb.bugs.michael@gmx.net> References: <43012F5A.4090104@redhat.com> <604aa79105081814222d78f31b@mail.gmail.com> <20050820141430.623b92cb.bugs.michael@gmx.net> Message-ID: <604aa79105082005331c47097e@mail.gmail.com> On 8/20/05, Michael Schwendt wrote: > Is it intentional, that redhat-artwork-0.126-1 still references > libcairo.so.1? doubtful... since redhat-artwork according to rpm doesn't have a requirement on libcairo this probably fell through the cracks. Is the autorequires probing that rpm does at buildtime turned off for redhat-artwork? -jef From bugs.michael at gmx.net Sat Aug 20 13:14:01 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 20 Aug 2005 15:14:01 +0200 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <604aa79105082005331c47097e@mail.gmail.com> References: <43012F5A.4090104@redhat.com> <604aa79105081814222d78f31b@mail.gmail.com> <20050820141430.623b92cb.bugs.michael@gmx.net> <604aa79105082005331c47097e@mail.gmail.com> Message-ID: <20050820151401.502d0efc.bugs.michael@gmx.net> On Sat, 20 Aug 2005 08:33:04 -0400, Jeff Spaleta wrote: > > Is it intentional, that redhat-artwork-0.126-1 still references > > libcairo.so.1? > > doubtful... since redhat-artwork according to rpm doesn't have a > requirement on libcairo this probably fell through the cracks. > > Is the autorequires probing that rpm does at buildtime turned off for > redhat-artwork? Want to know what my nose says? It tells me that this smells like it's disabled, because else the theme DSOs would pull in a lot of dependencies. Wasn't redhat-artwork a package which wanted Qt and other libraries even when user used only GNOME? Oh,...: $ rpm -q --changelog redhat-artwork |grep -i auto - autoreq 0 to avoid pointless dependencies - automated rebuild From jspaleta at gmail.com Sat Aug 20 15:54:43 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 20 Aug 2005 11:54:43 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <20050820151401.502d0efc.bugs.michael@gmx.net> References: <43012F5A.4090104@redhat.com> <604aa79105081814222d78f31b@mail.gmail.com> <20050820141430.623b92cb.bugs.michael@gmx.net> <604aa79105082005331c47097e@mail.gmail.com> <20050820151401.502d0efc.bugs.michael@gmx.net> Message-ID: <604aa79105082008546919c6@mail.gmail.com> On 8/20/05, Michael Schwendt wrote: > $ rpm -q --changelog redhat-artwork |grep -i auto > - autoreq 0 to avoid pointless dependencies > - automated rebuild you know... it wouldn't be at all a bad idea to try to compile a exhaustive list of this special case packages. Packages which have autoreq off will always be much more prone to falling through the cracks of common scripted tools to check for broken deps and we simply have to watch out for them in a more human intensive way as the need for rebuilds come up. I realize that special cases like this are going to be unavoidable I just want to make sure we keep a decent track of them so they don't bite users at release time. -jef From otaylor at redhat.com Sat Aug 20 18:09:58 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 20 Aug 2005 14:09:58 -0400 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <20050820151401.502d0efc.bugs.michael@gmx.net> References: <43012F5A.4090104@redhat.com> <604aa79105081814222d78f31b@mail.gmail.com> <20050820141430.623b92cb.bugs.michael@gmx.net> <604aa79105082005331c47097e@mail.gmail.com> <20050820151401.502d0efc.bugs.michael@gmx.net> Message-ID: <1124561398.20257.6.camel@localhost.localdomain> On Sat, 2005-08-20 at 15:14 +0200, Michael Schwendt wrote: > On Sat, 20 Aug 2005 08:33:04 -0400, Jeff Spaleta wrote: > > > > Is it intentional, that redhat-artwork-0.126-1 still references > > > libcairo.so.1? > > > > doubtful... since redhat-artwork according to rpm doesn't have a > > requirement on libcairo this probably fell through the cracks. > > > > Is the autorequires probing that rpm does at buildtime turned off for > > redhat-artwork? > > Want to know what my nose says? It tells me that this smells like > it's disabled, because else the theme DSOs would pull in a lot of > dependencies. Wasn't redhat-artwork a package which wanted Qt and > other libraries even when user used only GNOME? Good nose. It's to avoid Qt and GTK+-1.2 dependencies. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Sat Aug 20 19:32:38 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 20 Aug 2005 09:32:38 -1000 Subject: Rebuild of gtk+ dependent packages required In-Reply-To: <1124561398.20257.6.camel@localhost.localdomain> References: <43012F5A.4090104@redhat.com> <604aa79105081814222d78f31b@mail.gmail.com> <20050820141430.623b92cb.bugs.michael@gmx.net> <604aa79105082005331c47097e@mail.gmail.com> <20050820151401.502d0efc.bugs.michael@gmx.net> <1124561398.20257.6.camel@localhost.localdomain> Message-ID: <43078556.5050100@redhat.com> Owen Taylor wrote: >>>Is the autorequires probing that rpm does at buildtime turned off for >>>redhat-artwork? >> >>Want to know what my nose says? It tells me that this smells like >>it's disabled, because else the theme DSOs would pull in a lot of >>dependencies. Wasn't redhat-artwork a package which wanted Qt and >>other libraries even when user used only GNOME? > > > Good nose. It's to avoid Qt and GTK+-1.2 dependencies. > We could turn it back on, and filter only the deps that we don't want by name. Warren Togami wtogami at redhat.com From notting at redhat.com Mon Aug 22 21:43:36 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Aug 2005 17:43:36 -0400 Subject: update slang to 2.0? Message-ID: <20050822214336.GA23697@nostromo.devel.redhat.com> Any objections to updating slang to version 2.0 in rawhide/FC5? I can do the initial legwork. It includes native unicode support, as opposed to relying on the hacked-to-death UTF-8 slang patch we have now. It would require rebuilds of the following: In Core: newt slrn crypto-utils timidity++ system-config-securitylevel mc In Extras: caca aalib most jed Plus, we'd probably move compat-slang to providing the unicode hack one, as opposed to the pre-RHL8 version it has now. Bill From notting at redhat.com Mon Aug 22 21:50:04 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 22 Aug 2005 17:50:04 -0400 Subject: update slang to 2.0? In-Reply-To: <20050822214336.GA23697@nostromo.devel.redhat.com> References: <20050822214336.GA23697@nostromo.devel.redhat.com> Message-ID: <20050822215004.GB23697@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > In Core: > newt > slrn > crypto-utils > timidity++ > system-config-securitylevel > mc > > In Extras: > caca > aalib > most > jed AFAIK, of these, the ones that might require more than just a trivial rebuild: - newt (requires a trivial patch for a couple of box drawing/arrows, I have this) - slrn, jed (requires a new developmnet version) - most (requires a new released version) - mc (didn't investigate too much. Of course, this could probably be built against ncurses :) ) Bill From orion at cora.nwra.com Tue Aug 23 19:54:24 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 23 Aug 2005 13:54:24 -0600 Subject: -fPIC and x86_64 Message-ID: <430B7EF0.1010101@cora.nwra.com> I've gotten a request to build hdf with -fPIC because apparently when trying to build other packages that use it on x86_64 they complain. hdf only provides static libs. Is this the appropriate fix? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From notting at redhat.com Tue Aug 23 19:57:55 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Aug 2005 15:57:55 -0400 Subject: -fPIC and x86_64 In-Reply-To: <430B7EF0.1010101@cora.nwra.com> References: <430B7EF0.1010101@cora.nwra.com> Message-ID: <20050823195755.GA10855@nostromo.devel.redhat.com> Orion Poplawski (orion at cora.nwra.com) said: > I've gotten a request to build hdf with -fPIC because apparently when > trying to build other packages that use it on x86_64 they complain. hdf > only provides static libs. > > Is this the appropriate fix? If it's linked into a shared object later, yes. Bill From jakub at redhat.com Tue Aug 23 20:01:15 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 23 Aug 2005 16:01:15 -0400 Subject: -fPIC and x86_64 In-Reply-To: <20050823195755.GA10855@nostromo.devel.redhat.com> References: <430B7EF0.1010101@cora.nwra.com> <20050823195755.GA10855@nostromo.devel.redhat.com> Message-ID: <20050823200115.GE7403@devserv.devel.redhat.com> On Tue, Aug 23, 2005 at 03:57:55PM -0400, Bill Nottingham wrote: > Orion Poplawski (orion at cora.nwra.com) said: > > I've gotten a request to build hdf with -fPIC because apparently when > > trying to build other packages that use it on x86_64 they complain. hdf > > only provides static libs. > > > > Is this the appropriate fix? > > If it's linked into a shared object later, yes. But in that case not just for x86_64, but for all architectures. If the library is small and is expected to be only linked into small shared libraries, -fpic can be used instead. What small means is architecture dependent, on i386/x86_64 -fpic/-fPIC are identical, on other arches it can mean e.g. 4K got entries limit or similar. Jakub From orion at cora.nwra.com Tue Aug 23 20:04:04 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 23 Aug 2005 14:04:04 -0600 Subject: -fPIC and x86_64 In-Reply-To: <20050823200115.GE7403@devserv.devel.redhat.com> References: <430B7EF0.1010101@cora.nwra.com> <20050823195755.GA10855@nostromo.devel.redhat.com> <20050823200115.GE7403@devserv.devel.redhat.com> Message-ID: <430B8134.7030008@cora.nwra.com> Jakub Jelinek wrote: > But in that case not just for x86_64, but for all architectures. > If the library is small and is expected to be only linked into small shared > libraries, -fpic can be used instead. > What small means is architecture dependent, on i386/x86_64 -fpic/-fPIC are > identical, on other arches it can mean e.g. 4K got entries limit or similar. > > Jakub But I don't know what shared libraries it will be link to, so shouldn't I use -fPIC to be safe? Or are there other drawbacks? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From ed at eh3.com Tue Aug 23 20:42:07 2005 From: ed at eh3.com (Ed Hill) Date: Tue, 23 Aug 2005 16:42:07 -0400 Subject: -fPIC and x86_64 In-Reply-To: <430B8134.7030008@cora.nwra.com> References: <430B7EF0.1010101@cora.nwra.com> <20050823195755.GA10855@nostromo.devel.redhat.com> <20050823200115.GE7403@devserv.devel.redhat.com> <430B8134.7030008@cora.nwra.com> Message-ID: <1124829728.20751.247.camel@ernie> On Tue, 2005-08-23 at 14:04 -0600, Orion Poplawski wrote: > Jakub Jelinek wrote: > > But in that case not just for x86_64, but for all architectures. > > If the library is small and is expected to be only linked into small shared > > libraries, -fpic can be used instead. > > What small means is architecture dependent, on i386/x86_64 -fpic/-fPIC are > > identical, on other arches it can mean e.g. 4K got entries limit or similar. > > But I don't know what shared libraries it will be link to, so shouldn't > I use -fPIC to be safe? Or are there other drawbacks? Hi Orion, According to the GCC docs, -fpic and -fPIC are basically identical in i386 systems since they have no inherent limits on the GOT size. There is, however, a limit on PowerPC systems! So, in the interest of not wasting time on these fiddly annoyances that will only potentially bite Fedora ppc users, I'd skip -fpic and go straight to -fPIC. Please! ;-) And I think it would be nice if adding -fPIC was strongly recommended for all *.a libs since people almost inevitably want to use them (at some later date) to build shared libs. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From qspencer at ieee.org Tue Aug 23 20:49:46 2005 From: qspencer at ieee.org (Quentin Spencer) Date: Tue, 23 Aug 2005 15:49:46 -0500 Subject: -fPIC and x86_64 In-Reply-To: <1124829728.20751.247.camel@ernie> References: <430B7EF0.1010101@cora.nwra.com> <20050823195755.GA10855@nostromo.devel.redhat.com> <20050823200115.GE7403@devserv.devel.redhat.com> <430B8134.7030008@cora.nwra.com> <1124829728.20751.247.camel@ernie> Message-ID: <430B8BEA.6070203@ieee.org> Ed Hill wrote: >On Tue, 2005-08-23 at 14:04 -0600, Orion Poplawski wrote: > > >>Jakub Jelinek wrote: >> >> >>>But in that case not just for x86_64, but for all architectures. >>>If the library is small and is expected to be only linked into small shared >>>libraries, -fpic can be used instead. >>>What small means is architecture dependent, on i386/x86_64 -fpic/-fPIC are >>>identical, on other arches it can mean e.g. 4K got entries limit or similar. >>> >>> >>But I don't know what shared libraries it will be link to, so shouldn't >>I use -fPIC to be safe? Or are there other drawbacks? >> >> > >Hi Orion, > >According to the GCC docs, -fpic and -fPIC are basically identical in >i386 systems since they have no inherent limits on the GOT size. There >is, however, a limit on PowerPC systems! So, in the interest of not >wasting time on these fiddly annoyances that will only potentially bite >Fedora ppc users, I'd skip -fpic and go straight to -fPIC. Please! ;-) > >And I think it would be nice if adding -fPIC was strongly recommended >for all *.a libs since people almost inevitably want to use them (at >some later date) to build shared libs. > > While we're on this topic, I have a related question. I've been looking at the Debian version of a package I'm working on, and in their buildscripts they build a static library without -fPIC and then rebuild with -fPIC for the shared library. It seems like unnecessary extra compilation. Is there any possible performance loss (or any other side effect) that can come from using -fPIC? -Quentin From jakub at redhat.com Tue Aug 23 21:01:43 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 23 Aug 2005 17:01:43 -0400 Subject: -fPIC and x86_64 In-Reply-To: <430B8BEA.6070203@ieee.org> References: <430B7EF0.1010101@cora.nwra.com> <20050823195755.GA10855@nostromo.devel.redhat.com> <20050823200115.GE7403@devserv.devel.redhat.com> <430B8134.7030008@cora.nwra.com> <1124829728.20751.247.camel@ernie> <430B8BEA.6070203@ieee.org> Message-ID: <20050823210143.GF7403@devserv.devel.redhat.com> On Tue, Aug 23, 2005 at 03:49:46PM -0500, Quentin Spencer wrote: > While we're on this topic, I have a related question. I've been looking > at the Debian version of a package I'm working on, and in their > buildscripts they build a static library without -fPIC and then rebuild > with -fPIC for the shared library. It seems like unnecessary extra > compilation. Is there any possible performance loss (or any other side > effect) that can come from using -fPIC? Of course there is, at least on most architectures. There are 2 differences: 1) -fpic/-fPIC code can't must avoid text relocations, so where they would be needed, an indirection is needed instead. On many architectures (e.g. i386, ppc32, s390, s390x) a PIC register needs to be loaded on entry to most of the -fpic/-fPIC compiled routines, which means additional overhead. 2) with -fpic/-fPIC code, the compiler can't assume globally visible functions/variables defined in the same source as code referring to them will be defined in the same binary or shared library at runtime as well, which again can mean an indirection or a hop through PLT And -fPIC is on some architectures noticably slower than -fpic as well. Either it means more instructions to load the addresses (e.g. on sparc -fpic means one instruction that loads address, while -fPIC needs 3 instructions to do the same), or on some architectures -fPIC means double indirection. Jakub From orion at cora.nwra.com Tue Aug 23 21:12:53 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 23 Aug 2005 15:12:53 -0600 Subject: -fPIC and x86_64 In-Reply-To: <20050823210143.GF7403@devserv.devel.redhat.com> References: <430B7EF0.1010101@cora.nwra.com> <20050823195755.GA10855@nostromo.devel.redhat.com> <20050823200115.GE7403@devserv.devel.redhat.com> <430B8134.7030008@cora.nwra.com> <1124829728.20751.247.camel@ernie> <430B8BEA.6070203@ieee.org> <20050823210143.GF7403@devserv.devel.redhat.com> Message-ID: <430B9155.1060308@cora.nwra.com> Jakub - Thanks for the explanations. I've put in -fPIC in my HDF package, which only produces static libs so users are forced to use them in shared objects that use those libraries. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From rc040203 at freenet.de Tue Aug 23 23:57:08 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 24 Aug 2005 01:57:08 +0200 Subject: -fPIC and x86_64 In-Reply-To: <430B8BEA.6070203@ieee.org> References: <430B7EF0.1010101@cora.nwra.com> <20050823195755.GA10855@nostromo.devel.redhat.com> <20050823200115.GE7403@devserv.devel.redhat.com> <430B8134.7030008@cora.nwra.com> <1124829728.20751.247.camel@ernie> <430B8BEA.6070203@ieee.org> Message-ID: <1124841429.4363.37.camel@mccallum.corsepiu.local> On Tue, 2005-08-23 at 15:49 -0500, Quentin Spencer wrote: > While we're on this topic, I have a related question. I've been looking > at the Debian version of a package I'm working on, and in their > buildscripts they build a static library without -fPIC and then rebuild > with -fPIC for the shared library. It seems like unnecessary extra > compilation. Nope, this is the correct way. Ralf From jpo at di.uminho.pt Sat Aug 27 01:42:00 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Sat, 27 Aug 2005 02:42:00 +0100 Subject: Packages not listed in owners.list Message-ID: <430FC4E8.4080103@di.uminho.pt> Hi, The following packages aren't listed in the owners.list file (no bugzilla components): banner-1.3.1-2.fc4.src.rpm cproto-4.7c-7.fc4.src.rpm nedit-5.5-4.fc4.src.rpm perl-Text-Quoted-1.8-3.fc4.src.rpm perl-Unix-Statgrab-0.03-7.fc4.src.rpm scanssh-2.1-5.fc4.src.rpm wmacpi-1.34-4.fc4.src.rpm jpo PS - Only checked the FC-4 SRPMS. -- 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 * http://conferences.yapceurope.org/2005/ * http://braga.yapceurope.org/ -------------- 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 Sat Aug 27 18:35:09 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Sat, 27 Aug 2005 20:35:09 +0200 Subject: Packages not listed in owners.list In-Reply-To: <430FC4E8.4080103@di.uminho.pt> Message-ID: <200508271836.j7RIax3u007460@mail.linux-kernel.at> > The following packages aren't listed in the owners.list file > (no bugzilla components): > > banner-1.3.1-2.fc4.src.rpm [ ... ] > scanssh-2.1-5.fc4.src.rpm [ ... ] Oliver, you bad guy. :-) Thanks Jose. Have added those two. Best, Oliver From bugs.michael at gmx.net Tue Aug 30 08:41:19 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 30 Aug 2005 10:41:19 +0200 Subject: Maintainers must be reachable by email Message-ID: <20050830104119.35c1f94c.bugs.michael@gmx.net> Here's something that has come up a few times already: A fellow Fedora Extras contributor sends a private mail, probably to be treated confidentially, to another contributor. But the mail is rejected automatically due to rigorous or misconfigured SPAM filtering, IP blacklists or SPF problems. The sender tries again from another account, e.g. GMail, and once more, the mail is rejected in the same way. This is a frustrating experience for the sender. More frustrating than not getting a reply because perhaps a message is discarded silently. ;) There ought to be means of making sure any contributor can be reached by e-mail, in particular by the account sponsor. As a last resort, a second alternative e-mail address should be available in a place where it could be looked up by fellow contributors. Before taking this up to FESCO levels, I just want to raise awareness of this problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Tue Aug 30 08:45:05 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Aug 2005 22:45:05 -1000 Subject: Maintainers must be reachable by email In-Reply-To: <20050830104119.35c1f94c.bugs.michael@gmx.net> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> Message-ID: <43141C91.407@redhat.com> Michael Schwendt wrote: > Here's something that has come up a few times already: > > A fellow Fedora Extras contributor sends a private mail, probably to be > treated confidentially, to another contributor. But the mail is rejected > automatically due to rigorous or misconfigured SPAM filtering, IP > blacklists or SPF problems. The sender tries again from another account, > e.g. GMail, and once more, the mail is rejected in the same way. This is a > frustrating experience for the sender. More frustrating than not getting > a reply because perhaps a message is discarded silently. ;) > > There ought to be means of making sure any contributor can be reached by > e-mail, in particular by the account sponsor. As a last resort, a second > alternative e-mail address should be available in a place where it could > be looked up by fellow contributors. > > Before taking this up to FESCO levels, I just want to raise awareness of > this problem. If such a contributor is using CVS and is otherwise uncontactable, we could easily get their attention by disabling their CVS access temporarily. Such contributors are not very communicative and thus would not see this note. Warren Togami wtogami at redhat.com From dwmw2 at infradead.org Tue Aug 30 08:57:09 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 30 Aug 2005 10:57:09 +0200 Subject: Maintainers must be reachable by email In-Reply-To: <20050830104119.35c1f94c.bugs.michael@gmx.net> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> Message-ID: <1125392229.1093.13.camel@localhost.localdomain> On Tue, 2005-08-30 at 10:41 +0200, Michael Schwendt wrote: > A fellow Fedora Extras contributor sends a private mail, probably to be > treated confidentially, to another contributor. But the mail is rejected > automatically due to rigorous or misconfigured SPAM filtering, IP > blacklists or SPF problems. The sender tries again from another account, > e.g. GMail, and once more, the mail is rejected in the same way. This is a > frustrating experience for the sender. More frustrating than not getting > a reply because perhaps a message is discarded silently. ;) Any email address which is afflicted by the idiocy which is SPF shouldn't be acceptable as a maintainer's contact address -- just like mailing lists which only allow posts from subscribers. -- dwmw2 From alan at redhat.com Tue Aug 30 10:26:15 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 30 Aug 2005 06:26:15 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <20050830104119.35c1f94c.bugs.michael@gmx.net> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> Message-ID: <20050830102615.GA30102@devserv.devel.redhat.com> On Tue, Aug 30, 2005 at 10:41:19AM +0200, Michael Schwendt wrote: > blacklists or SPF problems. The sender tries again from another account, > e.g. GMail, and once more, the mail is rejected in the same way. This is a > frustrating experience for the sender. More frustrating than not getting > a reply because perhaps a message is discarded silently. ;) If it happens try again two or three days latter. Some of the allegedly well run spam host lists are used by big ISPs and are regularly tricked, confused, misfire - eg because of a dynamic IP address or the user may have genuinely misconfigured their system and not yet realised. > There ought to be means of making sure any contributor can be reached by > e-mail, in particular by the account sponsor. As a last resort, a second If you consistently can't reach them I suspect revoking your sponsorship should have the desired effect. Alan From tgl at redhat.com Tue Aug 30 14:45:05 2005 From: tgl at redhat.com (Tom Lane) Date: Tue, 30 Aug 2005 10:45:05 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <43141C91.407@redhat.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> Message-ID: <21599.1125413105@sss.pgh.pa.us> Warren Togami writes: > Michael Schwendt wrote: >> A fellow Fedora Extras contributor sends a private mail, probably to be >> treated confidentially, to another contributor. But the mail is rejected >> automatically due to rigorous or misconfigured SPAM filtering, IP >> blacklists or SPF problems. ... > If such a contributor is using CVS and is otherwise uncontactable, we > could easily get their attention by disabling their CVS access > temporarily. Such contributors are not very communicative and thus > would not see this note. I think you are oversimplifying this greatly. There are lots of people, me for instance, for whom the choice is either "spam filtering with teeth" or "abandon email, because you will never manage to find the real mail among the spam". I routinely reject several thousand junk messages per day using a combination of SMTP and procmail filtering. I really don't have a choice whether to filter (and I already spend much more time than I could wish tuning and maintaining the filters). This discussion seems to be headed in a direction fairly close to forbidding contributors from using spam filtering. That's not a recipe for improving communication; that's a recipe for losing contributors. I don't have a better solution I'm afraid, but I wonder whether this problem isn't being overblown. As long as you can contact someone via the mailing lists, you don't have a serious communication problem. Requiring contributors to keep an eye on certain specified lists doesn't seem unreasonable. regards, tom lane From smooge at gmail.com Tue Aug 30 14:59:27 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 30 Aug 2005 08:59:27 -0600 Subject: Maintainers must be reachable by email In-Reply-To: <21599.1125413105@sss.pgh.pa.us> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> Message-ID: <80d7e409050830075955c92b44@mail.gmail.com> On 8/30/05, Tom Lane wrote: > Warren Togami writes: > > Michael Schwendt wrote: > >> A fellow Fedora Extras contributor sends a private mail, probably to be > >> treated confidentially, to another contributor. But the mail is rejected > >> automatically due to rigorous or misconfigured SPAM filtering, IP > >> blacklists or SPF problems. ... > > > If such a contributor is using CVS and is otherwise uncontactable, we > > could easily get their attention by disabling their CVS access > > temporarily. Such contributors are not very communicative and thus > > would not see this note. > > I think you are oversimplifying this greatly. There are lots of people, > me for instance, for whom the choice is either "spam filtering with > teeth" or "abandon email, because you will never manage to find the > real mail among the spam". I routinely reject several thousand junk > messages per day using a combination of SMTP and procmail filtering. > I really don't have a choice whether to filter (and I already spend > much more time than I could wish tuning and maintaining the filters). > > This discussion seems to be headed in a direction fairly close to > forbidding contributors from using spam filtering. That's not a recipe > for improving communication; that's a recipe for losing contributors. > > I don't have a better solution I'm afraid, but I wonder whether this > problem isn't being overblown. As long as you can contact someone via > the mailing lists, you don't have a serious communication problem. > Requiring contributors to keep an eye on certain specified lists > doesn't seem unreasonable. Hmmm, one solution would be to set up 'vanity' accounts on a server that people who only want email from the build systems and such. However this is higher burden on the fedora systems administration staff in yet another machine to maintain. I was going to say that maintainers/contributers need to make sure that they have some account that is freely available to people to send email to .. but I hate agreeing with David on things :) -- Stephen J Smoogen. CSIRT/Linux System Administrator From skvidal at phy.duke.edu Tue Aug 30 15:06:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Aug 2005 11:06:27 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <80d7e409050830075955c92b44@mail.gmail.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> Message-ID: <1125414388.5875.4.camel@cutter> On Tue, 2005-08-30 at 08:59 -0600, Stephen J. Smoogen wrote: > On 8/30/05, Tom Lane wrote: > > Warren Togami writes: > > > Michael Schwendt wrote: > > >> A fellow Fedora Extras contributor sends a private mail, probably to be > > >> treated confidentially, to another contributor. But the mail is rejected > > >> automatically due to rigorous or misconfigured SPAM filtering, IP > > >> blacklists or SPF problems. ... > > > > > If such a contributor is using CVS and is otherwise uncontactable, we > > > could easily get their attention by disabling their CVS access > > > temporarily. Such contributors are not very communicative and thus > > > would not see this note. > > > > I think you are oversimplifying this greatly. There are lots of people, > > me for instance, for whom the choice is either "spam filtering with > > teeth" or "abandon email, because you will never manage to find the > > real mail among the spam". I routinely reject several thousand junk > > messages per day using a combination of SMTP and procmail filtering. > > I really don't have a choice whether to filter (and I already spend > > much more time than I could wish tuning and maintaining the filters). > > > > This discussion seems to be headed in a direction fairly close to > > forbidding contributors from using spam filtering. That's not a recipe > > for improving communication; that's a recipe for losing contributors. > > > > I don't have a better solution I'm afraid, but I wonder whether this > > problem isn't being overblown. As long as you can contact someone via > > the mailing lists, you don't have a serious communication problem. > > Requiring contributors to keep an eye on certain specified lists > > doesn't seem unreasonable. > > > Hmmm, one solution would be to set up 'vanity' accounts on a server > that people who only want email from the build systems and such. > However this is higher burden on the fedora systems administration > staff in yet another machine to maintain. > > I was going to say that maintainers/contributers need to make sure > that they have some account that is freely available to people to send > email to .. but I hate agreeing with David on things :) well there are already the @fedoraproject.org aliases. there are a couple of us with write access to add those. -sv From tgl at redhat.com Tue Aug 30 16:49:06 2005 From: tgl at redhat.com (Tom Lane) Date: Tue, 30 Aug 2005 12:49:06 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <80d7e409050830075955c92b44@mail.gmail.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> Message-ID: <22720.1125420546@sss.pgh.pa.us> "Stephen J. Smoogen" writes: > On 8/30/05, Tom Lane wrote: >> This discussion seems to be headed in a direction fairly close to >> forbidding contributors from using spam filtering. That's not a recipe >> for improving communication; that's a recipe for losing contributors. > I was going to say that maintainers/contributers need to make sure > that they have some account that is freely available to people to send > email to .. but I hate agreeing with David on things :) That'll just move the problem over one space. If you set up a new account for Fedora work, it'll start getting spam as soon as the address is publicly posted (and if it's not so posted, it's certainly of no use to solve the originally stated problem). I can't see that there's any hope of expecting people to maintain an address that is both widely available and spam-filter-free. regards, tom lane From gdk at redhat.com Tue Aug 30 16:49:34 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 30 Aug 2005 12:49:34 -0400 (EDT) Subject: Maintainers must be reachable by email In-Reply-To: <22720.1125420546@sss.pgh.pa.us> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> Message-ID: On Tue, 30 Aug 2005, Tom Lane wrote: > That'll just move the problem over one space. If you set up a new > account for Fedora work, it'll start getting spam as soon as the address > is publicly posted (and if it's not so posted, it's certainly of no use > to solve the originally stated problem). I can't see that there's any > hope of expecting people to maintain an address that is both widely > available and spam-filter-free. /me wonders if giving people accounts on fedoraproject dot org would be a useful idea. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From sopwith at redhat.com Tue Aug 30 16:59:12 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 30 Aug 2005 12:59:12 -0400 (EDT) Subject: Maintainers must be reachable by email In-Reply-To: References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> Message-ID: On Tue, 30 Aug 2005, Greg DeKoenigsberg wrote: > On Tue, 30 Aug 2005, Tom Lane wrote: > > > That'll just move the problem over one space. If you set up a new > > account for Fedora work, it'll start getting spam as soon as the address > > is publicly posted (and if it's not so posted, it's certainly of no use > > to solve the originally stated problem). I can't see that there's any > > hope of expecting people to maintain an address that is both widely > > available and spam-filter-free. > > /me wonders if giving people accounts on fedoraproject dot org would be a > useful idea. Google, Yahoo, and Microsoft are in the business of managing free e-mail accounts - might as well let them put up the resources for that. We do have aliases for all accounts @fedora.redhat.com, if people dislike the idea of using addresses @gmail.com... Best, -- Elliot Pioneers get the Arrows. Settlers get the Land. From skvidal at phy.duke.edu Tue Aug 30 17:13:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 30 Aug 2005 13:13:13 -0400 Subject: Maintainers must be reachable by email In-Reply-To: References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> Message-ID: <1125421993.5875.8.camel@cutter> On Tue, 2005-08-30 at 12:49 -0400, Greg DeKoenigsberg wrote: > On Tue, 30 Aug 2005, Tom Lane wrote: > > > That'll just move the problem over one space. If you set up a new > > account for Fedora work, it'll start getting spam as soon as the address > > is publicly posted (and if it's not so posted, it's certainly of no use > > to solve the originally stated problem). I can't see that there's any > > hope of expecting people to maintain an address that is both widely > > available and spam-filter-free. > > /me wonders if giving people accounts on fedoraproject dot org would be a > useful idea. > accounts? or aliases on fedoraproject.org? If it is accounts then we need to talk about that for a bit. -sv From fche at redhat.com Tue Aug 30 17:15:52 2005 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 30 Aug 2005 13:15:52 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <1125421993.5875.8.camel@cutter> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> Message-ID: <20050830171552.GC31063@redhat.com> Hi - On Tue, Aug 30, 2005 at 01:13:13PM -0400, seth vidal wrote: > > > That'll just move the problem over one space. If you set up a new > > > account for Fedora work, it'll start getting spam as soon as the address > > > is publicly posted [...] > > > > /me wonders if giving people accounts on fedoraproject dot org would be a > > useful idea. > > accounts? or aliases on fedoraproject.org? But it doesn't matter - Tom's point was that, regardless, spam will flow to any new email address. I suspect a better solution is simply to encourage maintainers to monitor their spam filters, to avoid missing fedora-related traffic. Someone who remains troublingly unreachable can be dealt with on a case-by-case basis. - FChE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gdk at redhat.com Tue Aug 30 17:13:47 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 30 Aug 2005 13:13:47 -0400 (EDT) Subject: Maintainers must be reachable by email In-Reply-To: <1125421993.5875.8.camel@cutter> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> Message-ID: s/accounts/aliases --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan On Tue, 30 Aug 2005, seth vidal wrote: > On Tue, 2005-08-30 at 12:49 -0400, Greg DeKoenigsberg wrote: > > On Tue, 30 Aug 2005, Tom Lane wrote: > > > > > That'll just move the problem over one space. If you set up a new > > > account for Fedora work, it'll start getting spam as soon as the address > > > is publicly posted (and if it's not so posted, it's certainly of no use > > > to solve the originally stated problem). I can't see that there's any > > > hope of expecting people to maintain an address that is both widely > > > available and spam-filter-free. > > > > /me wonders if giving people accounts on fedoraproject dot org would be a > > useful idea. > > > > accounts? or aliases on fedoraproject.org? > > If it is accounts then we need to talk about that for a bit. > > -sv > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From jspaleta at gmail.com Tue Aug 30 17:39:37 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 30 Aug 2005 13:39:37 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <20050830171552.GC31063@redhat.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> Message-ID: <604aa79105083010394d88ba5a@mail.gmail.com> On 8/30/05, Frank Ch. Eigler wrote: > But it doesn't matter - Tom's point was that, regardless, spam will > flow to any new email address. Not if the new address only accepts mail from other fedoraproject.org addresses. What I'm getting from this thread is that there needs to be a dedicated way for people inside the project to talk to other people inside the project...privately. Surely there is a technical solution to this problem involving a mail server, aliases and some gpg signature checking. Maintainers do have gpg keys on file right? So any mail going to a fedoraproject.org alias has its signature checked to see if the mail is really from a registered contributor in the accounts system. That should prevent spam to such an alias to a very great extent. Of course... just cutting off an out-of-touch maintainers cvs access would be my personal choice..but I'm evil. -jef"95% evil, 5% coffee"spaleta From sopwith at redhat.com Tue Aug 30 18:00:36 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 30 Aug 2005 14:00:36 -0400 (EDT) Subject: Bzzzt Message-ID: I've noticed that someone updated and built an Extras package for FC-4 but not 'devel' (note to Gavin Henry: I will not expose your identity as the culprit with rdiff-backup :). This kind of bitrot will bite us in the long run - ideas on preventing it? Best, -- Elliot From roland at redhat.com Tue Aug 30 18:02:48 2005 From: roland at redhat.com (Roland McGrath) Date: Tue, 30 Aug 2005 11:02:48 -0700 (PDT) Subject: Bzzzt In-Reply-To: Elliot Lee's message of Tuesday, 30 August 2005 14:00:36 -0400 Message-ID: <20050830180248.4CB78180A18@magilla.sf.frob.com> I think nagmail a la broken dependencies complainer should suffice. From fedora at leemhuis.info Tue Aug 30 18:45:13 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 30 Aug 2005 20:45:13 +0200 Subject: Bzzzt In-Reply-To: References: Message-ID: <1125427513.3194.9.camel@localhost.localdomain> Am Dienstag, den 30.08.2005, 14:00 -0400 schrieb Elliot Lee: > [...] > This kind of bitrot will bite us in the long run - ideas on preventing it? I would suggest a script that checks a) for this kind of bitrot b) unmet dependencies in the trees (similar to the stuff in the daily rawhide-report; makes life also easier when big changes hit rawhide [stuff like cairo, python, gcc in the past]) It could run each time when new extras-packages are pushed; the output could be appended to those "Fedora Extras * Package Build Report" mails. Just my 2 cent -- Thorsten Leemhuis From mharris at redhat.com Wed Aug 31 03:40:38 2005 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 30 Aug 2005 23:40:38 -0400 Subject: Request for volunteers to help track down packages that use /usr/X11R6 Message-ID: <431526B6.1010404@redhat.com> Overview: ~~~~~~~~ The X.Org Foundation has finally changed X11 to install itself into the /usr heirarchy by default instead of the /usr/X11R6 hierarchy. The basic rationale is that with modern packaging systems like rpm, deb, etc., there is no need to isolate the X Window System into its own private hierarchy on the filesystem. Originally, the /usr/X11R6 directory was intended to strictly be the location where X11R6 itself would get installed. Over time however various other 3rd party software packages, addons and other stuff has infiltrated into the /usr/X11R6 heirarchy for no really good reason, and some of it still sits in there today. A year or two ago, I knew this change would be coming in the future, and sent out email to inform other package maintainers that they should update their packages to install their files in FHS compliant directories instead of abusing the /usr/X11R6 heirarchy. I'm not sure how many people actually listened though, so we're about to find out. ;o) What's changing specifically: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ X.Org X11 will no longer use the /usr/X11R6 directory hierarchy at all. It uses /usr, and installs files where you'd expect them to be found within that heirarchy more or less (although it is a bit buggy in this regard currently, that'll be fixed prior to X11R7's final release). The libraries, binaries, fonts, config files, data files - everything is moving. Along with this upstream X.Org change, there will be a number of backward compatibility issues that we'll face, where we may need to provide backward compatible symlinks for cases like applications hard coding the path to X binaries instead of using "which " and similar. We'll be keeping an eye on such issues and considering where we should provide compatibility links. What we'd like volunteers to help with: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1) A lot of existing Fedora Core, Fedora Extras and other 3rd party packages currently install themselves into /usr/X11R6, need to be updated to install themselves in a more appropriate location under /usr, using %{_datadir} and friends in their rpm specfiles. Volunteers are needed who are willing to take on the task of reporting bugs against the offending packages, and preferably also attaching patches to fix the rpms. 2) A number of packages might have shell scripts, .desktop files, or other things with hard coded paths to binaries such as /usr/X11R6/bin/xterm, or to data files, or other files traditionally installed under /usr/X11R6. Please report bugs against these packages, and where possible, change them to use "which " instead of hard coding the path to the executable/file directly. In some cases dynamic solution might not work, so hard code the new path in that case unless there's another appropriate solution apparent. 3) If you can personally think of any application or compat problems that might occur when the changeover is made, please report them to me via email in advance, so we can try to find a solution sooner than later. This message is being sent out to encourage community involvement in the process, and to help weed out problems sooner in the development cycle than later on, as there is likely to be a fair amount of package churn, so we'd like to get things in order far far in advance of FC5test1. Thanks in advance for any feedback, and also to any volunteers who decide to help out. From jgarzik at redhat.com Wed Aug 31 04:11:50 2005 From: jgarzik at redhat.com (Jeff Garzik) Date: Wed, 31 Aug 2005 00:11:50 -0400 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <431526B6.1010404@redhat.com> References: <431526B6.1010404@redhat.com> Message-ID: <20050831041149.GE14327@devserv.devel.redhat.com> On Tue, Aug 30, 2005 at 11:40:38PM -0400, Mike A. Harris wrote: > What's changing specifically: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > X.Org X11 will no longer use the /usr/X11R6 directory hierarchy > at all. It uses /usr, and installs files where you'd expect > them to be found within that heirarchy more or less (although > it is a bit buggy in this regard currently, that'll be fixed > prior to X11R7's final release). The libraries, binaries, > fonts, config files, data files - everything is moving. Yay! Question... when this switchover happens, will X be packaged such that it is possible to set up a /usr/X11R6-free x11-xorg setup? That would greatly aid developers, to see what major breakage occurs when the x11-org-compat-symlinks package is omitted. Jeff From toshio at tiki-lounge.com Wed Aug 31 04:41:25 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Tue, 30 Aug 2005 21:41:25 -0700 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <431526B6.1010404@redhat.com> References: <431526B6.1010404@redhat.com> Message-ID: <1125463285.3266.69.camel@localhost> On Tue, 2005-08-30 at 23:40 -0400, Mike A. Harris wrote: > What we'd like volunteers to help with: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1) A lot of existing Fedora Core, Fedora Extras and other 3rd > party packages currently install themselves into /usr/X11R6, > need to be updated to install themselves in a more > appropriate location under /usr, using %{_datadir} and > friends in their rpm specfiles. Volunteers are needed who > are willing to take on the task of reporting bugs against > the offending packages, and preferably also attaching > patches to fix the rpms. I'm attaching a quick and dirty python hack that can extract this from a yum filelist cache. You can run it if you like or give me the following information and I can do it: 1) I'm scanning for inclusion of the following partial pathnames: /usr/X11 /usr/bin/X11 /usr/lib/X11 /usr/lib64/X11 Are any of these wrong? Are there any more you can think of? 2) Which repositories do you want it run against? development, development-extras, livna-*, ? 3) Which packages should I exclude from a final report? Anything with xorg-x11 in front of it? Report it all and you'll sift the xorg packages out? How to run the script as is: As root enable the repositories you wish to scan in /etc/yum.repos.d/* and disable the rest. rm -f /var/cache/yum/*/filelists.xml.gz yum provides /some/nonexistent/pathname/here As normal user: python scandir.py| sort | uniq >/var/tmp/x11-pkgs -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: scandir.py Type: text/x-python Size: 1414 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Wed Aug 31 04:46:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 31 Aug 2005 00:46:14 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <604aa79105083010394d88ba5a@mail.gmail.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> Message-ID: <1125463574.9260.66.camel@cutter> On Tue, 2005-08-30 at 13:39 -0400, Jeff Spaleta wrote: > On 8/30/05, Frank Ch. Eigler wrote: > > But it doesn't matter - Tom's point was that, regardless, spam will > > flow to any new email address. > > Not if the new address only accepts mail from other fedoraproject.org addresses. > > What I'm getting from this thread is that there needs to be a > dedicated way for people inside the project to talk to other people > inside the project...privately. > > Surely there is a technical solution to this problem involving a mail > server, aliases and some gpg signature checking. Maintainers do have > gpg keys on file right? So any mail going to a fedoraproject.org > alias has its signature checked to see if the mail is really from a > registered contributor in the accounts system. That should prevent > spam to such an alias to a very great extent. Of course... just > cutting off an out-of-touch maintainers cvs access would be my > personal choice..but I'm evil. So you want to setup a filter that does all that shit on the server? Screw that - if someone wants to be a paranoid nutjob with their email that's what procmail is for. You can set that up for yourself but doing it all on the mail server - thppppppppppt. -sv From rc040203 at freenet.de Wed Aug 31 07:17:31 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 31 Aug 2005 09:17:31 +0200 Subject: Request for volunteers to help track down packages that use /usr/X11R6 In-Reply-To: <431526B6.1010404@redhat.com> References: <431526B6.1010404@redhat.com> Message-ID: <1125472651.16878.130.camel@mccallum.corsepiu.local> On Tue, 2005-08-30 at 23:40 -0400, Mike A. Harris wrote: > 3) If you can personally think of any application or compat > problems that might occur when the changeover is made, > please report them to me via email in advance, so we can > try to find a solution sooner than later. Probably 100s of packages have some form of /usr/X*/{lib|lib64|include} or similar hard-coded into configure scripts, build scripts, Makefiles and the like. > as there > is likely to be a fair amount of package churn, so we'd > like to get things in order far far in advance of > FC5test1. Well, I would expect you will not be able to avoid having to provide a compatibility package for at least the next couple of years. Ralf From cra at WPI.EDU Wed Aug 31 14:55:10 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 31 Aug 2005 10:55:10 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <1125463574.9260.66.camel@cutter> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> Message-ID: <20050831145510.GD16426@angus.ind.WPI.EDU> On Wed, Aug 31, 2005 at 12:46:14AM -0400, seth vidal wrote: > On Tue, 2005-08-30 at 13:39 -0400, Jeff Spaleta wrote: > > gpg keys on file right? So any mail going to a fedoraproject.org > > alias has its signature checked to see if the mail is really from a > > registered contributor in the accounts system. That should prevent > So you want to setup a filter that does all that shit on the server? > Screw that - if someone wants to be a paranoid nutjob with their email Actually, that sounds a lot like how DKIM works in a mailing-list scenario. It doesn't prevent spam, but it provides a way to trust that the source of the e-mail hasn't been spoofed. From jspaleta at gmail.com Wed Aug 31 20:56:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 31 Aug 2005 16:56:40 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <1125463574.9260.66.camel@cutter> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> Message-ID: <604aa7910508311356202e48a8@mail.gmail.com> On 8/31/05, seth vidal wrote: > So you want to setup a filter that does all that shit on the server? I'm not sure what i want, other than knowing i want a pony. I'm just trying to re-state what I think is being asked for and trying to get to a workable technical solution. I don't have a dog in this race personally. I'm not drowning in spam yet.. and as everyone on the mailinglists can tell..I'm spending way to much time as it is yapping away with other maintainers. Group A needs to communicate about packages with Group B..privately. Group B is not seeing email from Group A due to too much spam. How do we make it easier for Group A and Group B to communicate? Perhaps email itself is the problem here. Would it be technically possible to have some sort of centralized bulletin board system that can handle person-to-person notes and then require maintainers to check such a system once-a-week-ish? -jef From fche at redhat.com Wed Aug 31 21:00:09 2005 From: fche at redhat.com (Frank Ch. Eigler) Date: Wed, 31 Aug 2005 17:00:09 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <604aa7910508311356202e48a8@mail.gmail.com> References: <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> Message-ID: <20050831210009.GA8528@redhat.com> Hi - On Wed, Aug 31, 2005 at 04:56:40PM -0400, Jeff Spaleta wrote: > > So you want to setup a filter that does all that shit on the server? > [...] > Group A needs to communicate about packages with Group B..privately. Actually I don't recall confidentiality of such communication as being the problem. Wasn't it the unreliability? - FChE From jspaleta at gmail.com Wed Aug 31 21:04:12 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 31 Aug 2005 17:04:12 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <20050831210009.GA8528@redhat.com> References: <43141C91.407@redhat.com> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> <20050831210009.GA8528@redhat.com> Message-ID: <604aa79105083114046b27f958@mail.gmail.com> On 8/31/05, Frank Ch. Eigler wrote: > Actually I don't recall confidentiality of such communication > as being the problem. Wasn't it the unreliability? if confidentiality isnt required... then we have this here mailinglist..for maintainers and other contributors. Is it unduly burdensome to require all maintainers to keep up with this list? -jef From jwboyer at jdub.homelinux.org Wed Aug 31 22:57:01 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 31 Aug 2005 17:57:01 -0500 Subject: Maintainers must be reachable by email In-Reply-To: <604aa7910508311356202e48a8@mail.gmail.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> Message-ID: <1125529022.13179.5.camel@yoda.jdub.homelinux.org> On Wed, 2005-08-31 at 16:56 -0400, Jeff Spaleta wrote: > On 8/31/05, seth vidal wrote: > > So you want to setup a filter that does all that shit on the server? > > I'm not sure what i want, other than knowing i want a pony. I'm just > trying to re-state what I think is being asked for and trying to get > to a workable technical solution. I don't have a dog in this race > personally. I'm not drowning in spam yet.. and as everyone on the > mailinglists can tell..I'm spending way to much time as it is yapping > away with other maintainers. > > Group A needs to communicate about packages with Group B..privately. > Group B is not seeing email from Group A due to too much spam. How do > we make it easier for Group A and Group B to communicate? Perhaps > email itself is the problem here. Would it be technically possible to > have some sort of centralized bulletin board system that can handle > person-to-person notes and then require maintainers to check such a > system once-a-week-ish? Spam isn't the only reason mail doesn't get through. I can't email anyone with an @bigpond.net.au account because that ISP seems to think mail servers running from a dynamic IP address are evil. Same with @aol.com addresses and a few others. The fact is, my mail server works just fine, it's up 98% of the time, it's DNS entry is constantly refreshed, and it's not an open relay. Apparently that doesn't matter though, and I'm too cheap to pay extra money for a static IP :). I don't consider this nearly as large of an issue as the spam filter stuff, but just wanted to point out that other reasons for mail not getting through are possible. josh From skvidal at phy.duke.edu Wed Aug 31 23:33:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 31 Aug 2005 19:33:38 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <604aa7910508311356202e48a8@mail.gmail.com> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> Message-ID: <1125531218.20273.0.camel@cutter> On Wed, 2005-08-31 at 16:56 -0400, Jeff Spaleta wrote: > On 8/31/05, seth vidal wrote: > > So you want to setup a filter that does all that shit on the server? > > I'm not sure what i want, other than knowing i want a pony. I'm just > trying to re-state what I think is being asked for and trying to get > to a workable technical solution. I don't have a dog in this race > personally. I'm not drowning in spam yet.. and as everyone on the > mailinglists can tell..I'm spending way to much time as it is yapping > away with other maintainers. > > Group A needs to communicate about packages with Group B..privately. > Group B is not seeing email from Group A due to too much spam. How do > we make it easier for Group A and Group B to communicate? Perhaps > email itself is the problem here. Would it be technically possible to > have some sort of centralized bulletin board system that can handle > person-to-person notes and then require maintainers to check such a > system once-a-week-ish? what's so bad about the -maintainers mailing list? -sv From tgl at redhat.com Wed Aug 31 23:33:57 2005 From: tgl at redhat.com (Tom Lane) Date: Wed, 31 Aug 2005 19:33:57 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <1125529022.13179.5.camel@yoda.jdub.homelinux.org> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> <1125529022.13179.5.camel@yoda.jdub.homelinux.org> Message-ID: <5666.1125531237@sss.pgh.pa.us> Josh Boyer writes: > Spam isn't the only reason mail doesn't get through. I can't email > anyone with an @bigpond.net.au account because that ISP seems to think > mail servers running from a dynamic IP address are evil. Well, actually, spam *is* the reason your mail doesn't get through. Neither that ISP nor anybody else had such policies, until the spam (and virus) problem got so bad as to make wholesale mail blocking seem essential. I don't think anyone who has such a policy particularly likes it, they just don't feel they have much alternative. > I don't consider this nearly as large of an issue as the spam filter > stuff, That is a spam filter, and at least in my usage, it probably blocks as much or more junk as subsequent procmail tests. regards, tom lane From gdk at redhat.com Wed Aug 31 23:34:19 2005 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 31 Aug 2005 19:34:19 -0400 (EDT) Subject: Maintainers must be reachable by email In-Reply-To: <1125531218.20273.0.camel@cutter> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <43141C91.407@redhat.com> <21599.1125413105@sss.pgh.pa.us> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> <1125531218.20273.0.camel@cutter> Message-ID: On Wed, 31 Aug 2005, seth vidal wrote: > what's so bad about the -maintainers mailing list? +1. I think we're overthinking this. One thing we could do: create an RSS feed for Extras maintainers on fp.org. If you're a maintainer, keep a blog. Or not. When in doubt, just check the archives of the mailing list. --g _____________________ ____________________________________________ Greg DeKoenigsberg ] [ the future masters of technology will have Community Relations ] [ to be lighthearted and intelligent. the Red Hat ] [ machine easily masters the grim and the ] [ dumb. --mcluhan From jspaleta at gmail.com Wed Aug 31 23:53:27 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 31 Aug 2005 19:53:27 -0400 Subject: Maintainers must be reachable by email In-Reply-To: <1125531218.20273.0.camel@cutter> References: <20050830104119.35c1f94c.bugs.michael@gmx.net> <80d7e409050830075955c92b44@mail.gmail.com> <22720.1125420546@sss.pgh.pa.us> <1125421993.5875.8.camel@cutter> <20050830171552.GC31063@redhat.com> <604aa79105083010394d88ba5a@mail.gmail.com> <1125463574.9260.66.camel@cutter> <604aa7910508311356202e48a8@mail.gmail.com> <1125531218.20273.0.camel@cutter> Message-ID: <604aa79105083116532a218fab@mail.gmail.com> On 8/31/05, seth vidal wrote: > what's so bad about the -maintainers mailing list? I've no problem with it for public discussion. But the original post in this thread from Mr. Schwendt, specifically talked a problem with private communication between maintainers. I can't speak as to why he needs private communication with another contributor. -jef