From peter at thecodergeek.com Tue May 1 03:13:51 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 30 Apr 2007 20:13:51 -0700 Subject: No access on fedora extras cvs In-Reply-To: <1177938741.3189.40.camel@localhost.localdomain> References: <1177938741.3189.40.camel@localhost.localdomain> Message-ID: <1177989231.3440.20.camel@tuxhugs> On Mon, 2007-04-30 at 15:12 +0200, Maxime Carron wrote: > **** Access denied: mxcarron is not in ACL for > rpms/pypar2/devel > cvs commit: Pre-commit check failed > cvs [commit aborted]: correct above errors first! > cvs commit: saving log message in /tmp/cvsTYkETc > The ACLs sync with the account system every hour (or is it every half-hour?), so please retry your cvs-import and let us know if you're still having troubles. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Tue May 1 04:27:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 May 2007 00:27:03 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070427151404.GC3031@free.fr> References: <1177577793.2755.303.camel@pmac.infradead.org> <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> Message-ID: <20070501042703.GC11331@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > On Fri, Apr 27, 2007 at 07:11:00PM +0400, Dmitry Butskoy wrote: > > Patrice Dumas wrote: > > >... I'd prefer bin32 > > Oh, no!... > > > > /bin, /usr/bin, since the epoch... > > More precisely, I mean > /bin, /usr/bin for the primary arch, and > /bin32, /usr/bin32 for the secondary arch (32 bits) on x86_64. ... which makes your i386-on-x86_64 packages and your i386 packages... different. (And says nothing about incompatibilities with UNIX tradition, the LSB, the FHS, and even being able to sanely manipulate things if you want 1 i386 binary and everything else x86_64.) The right way to go about this is determine *what people need to do*; at a minimum, what people seem to want: - 32-bit firefox on x86_64, because they need to access content only available via proprietary plugins - installation of third-party software that is only available for the secondary arch, in a way that allows it to run - doing development for a non-primary arch without setting up a chroot. (mock works well for RPMS. mock for random 'compile this' is a PITA.) And, once you have your use cases, you solve around that. Bill From notting at redhat.com Tue May 1 04:34:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 May 2007 00:34:59 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4631AA09.4090805@fedoraproject.org> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> <4631A0FF.70209@leemhuis.info> <4631AA09.4090805@fedoraproject.org> Message-ID: <20070501043459.GD11331@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Right. Whatever the correct solution is should be applied across the > repository instead of complete inconsistency. Openoffice.org with > multiple language packs, KDE with a single language pack and Firefox > with everything in the same package. Firefox having everything in the > same package is a common user complaint in fedora-list and forums > especially since it bloats the package to over double the usual size and > the extensions are visible in the user interface. So, you're suggesting picking a fight with every upstream that does it the wrong way? That will be ... fun. Bill From sundaram at fedoraproject.org Tue May 1 04:41:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 10:11:41 +0530 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <20070501043459.GD11331@nostromo.devel.redhat.com> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> <4631A0FF.70209@leemhuis.info> <4631AA09.4090805@fedoraproject.org> <20070501043459.GD11331@nostromo.devel.redhat.com> Message-ID: <4636C505.3020104@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> Right. Whatever the correct solution is should be applied across the >> repository instead of complete inconsistency. Openoffice.org with >> multiple language packs, KDE with a single language pack and Firefox >> with everything in the same package. Firefox having everything in the >> same package is a common user complaint in fedora-list and forums >> especially since it bloats the package to over double the usual size and >> the extensions are visible in the user interface. > > So, you're suggesting picking a fight with every upstream that > does it the wrong way? That will be ... fun. Not a fight. Act as a bridge for users, collaborate with upstream (considering that we are a active part of upstream in this case) and figure out a good solution that does not bloat the package and have other effects like more resource use or slower speed of startup. Some of these details are just coming out with good packaging guidelines on how we deal with language packs instead of every group doing it's own thing. There must be more common ground here. Rahul From notting at redhat.com Tue May 1 05:04:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 May 2007 01:04:22 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4636C505.3020104@fedoraproject.org> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> <4631A0FF.70209@leemhuis.info> <4631AA09.4090805@fedoraproject.org> <20070501043459.GD11331@nostromo.devel.redhat.com> <4636C505.3020104@fedoraproject.org> Message-ID: <20070501050422.GF11331@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Not a fight. Act as a bridge for users, collaborate with upstream > (considering that we are a active part of upstream in this case) and > figure out a good solution that does not bloat the package and have > other effects like more resource use or slower speed of startup. If you want to solve the package size issue, switch to presto; this would save the download size much more than splitting off packages for language packs would. Bill From sundaram at fedoraproject.org Tue May 1 05:15:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 01 May 2007 10:45:25 +0530 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <20070501050422.GF11331@nostromo.devel.redhat.com> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> <4631A0FF.70209@leemhuis.info> <4631AA09.4090805@fedoraproject.org> <20070501043459.GD11331@nostromo.devel.redhat.com> <4636C505.3020104@fedoraproject.org> <20070501050422.GF11331@nostromo.devel.redhat.com> Message-ID: <4636CCED.2050304@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> Not a fight. Act as a bridge for users, collaborate with upstream >> (considering that we are a active part of upstream in this case) and >> figure out a good solution that does not bloat the package and have >> other effects like more resource use or slower speed of startup. > > If you want to solve the package size issue, switch to presto; > this would save the download size much more than splitting > off packages for language packs would. I am using it already. Presto only would save sizes on updates. Not the initial download size or other issues. The bigger problem though is that Fedora does not have a consistent and documented approach to deal with language packs throughout the distribution. Rahul From paul at city-fan.org Tue May 1 07:16:16 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 01 May 2007 08:16:16 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070430174043.696263de@daggett> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <4635EDFC.9090704@redhat.com> <20070430194603.GF13906@neu.nirvana> <20070430174043.696263de@daggett> Message-ID: <4636E940.6030801@city-fan.org> Ed Hill wrote: > On Mon, 30 Apr 2007 21:46:04 +0200 Axel Thimm wrote: >> On Mon, Apr 30, 2007 at 03:24:12PM +0200, Phil Knirsch wrote: >> >>> The solution debian and Gentoo iirc use which are basically >>> buildroots is the only way i know how you can cleanly separate >>> various archs on one system. Sadly you'll then loose the common and >>> sharable files, but any other solution will need very carefull and >>> detailed planing. >> Personally I prefer banning multilib in rpm for good and if that would >> be best done by using chroot solutions, I'm all for it. The multilib >> implementation within rpm magic just isn't scaling and produces more >> bugs on the way than we can fix. > > > I'm not familiar with the chroots used in Debian or Gentoo. Can someone > please say a few words about their usability? I'm just wondering about > the following: > > - do chroots require special permissions or group memberships? > > - once you are in a chroot isn't it nearly impossible to > access files outside it? Put differently, are there some > interesting soft-linking or re-mounting gymnastics or other > hacks going on here to get at, say, your ${HOME} or other > random directories from a chroot-ed program? > > It just seems to me that chroots are probably a lot less usable than > binaries placed in {,/usr}/{,s}bin64 or similar. chroots and SELinux don't play nicely together at the moment either. You'd need to replicate the entire set of default contexts into each chroot. Paul. From dominik at greysector.net Tue May 1 08:58:36 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 1 May 2007 10:58:36 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070501042703.GC11331@nostromo.devel.redhat.com> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> Message-ID: <20070501085835.GB8030@ryvius.pekin.waw.pl> On Tuesday, 01 May 2007 at 06:27, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > On Fri, Apr 27, 2007 at 07:11:00PM +0400, Dmitry Butskoy wrote: > > > Patrice Dumas wrote: > > > >... I'd prefer bin32 > > > Oh, no!... > > > > > > /bin, /usr/bin, since the epoch... > > > > More precisely, I mean > > /bin, /usr/bin for the primary arch, and > > /bin32, /usr/bin32 for the secondary arch (32 bits) on x86_64. > > ... which makes your i386-on-x86_64 packages and your i386 > packages... different. > > (And says nothing about incompatibilities with UNIX tradition, > the LSB, the FHS, and even being able to sanely manipulate > things if you want 1 i386 binary and everything else x86_64.) > > The right way to go about this is determine *what people need > to do*; at a minimum, what people seem to want: > > - 32-bit firefox on x86_64, because they need to access content > only available via proprietary plugins We have nspluginwrapper for 64bit firefox. > - installation of third-party software that is only available for the > secondary arch, in a way that allows it to run Right. Google Earth is one example. > - doing development for a non-primary arch without setting up > a chroot. (mock works well for RPMS. mock for random > 'compile this' is a PITA.) Right. > And, once you have your use cases, you solve around that. Those cover all my needs. Current solution works for me (sans the already known problems). Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Tue May 1 09:32:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 11:32:19 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1177774282.2831.84.camel@pmac.infradead.org> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> Message-ID: <20070501093219.GC10108@neu.nirvana> I'm removing all your references on masturbations and characterizing me as a kook and the like. Please don't readd them or any other new non-adolescent vocabulary. On Sat, Apr 28, 2007 at 04:31:22PM +0100, David Woodhouse wrote: > > > -> o Rewrite almost all specfiles to sub-subpackage *-bin and manage the > > > -> conflicting bin suppackages > > > > Where does this reference "packages that contain bin and libs"? Why do > > you continue to do apples vs oranges? Why don't you *read* before > > replying? > > I compared your estimate of the number of specfiles we'd need to modify > ("almost all"), with mine ("10-20%"). Why do you find that so confusing? No, you wrongly quoted my 14% as confirming the validity of your estimation, which I now repeadetly explained that this is not the case. All it was was an exact number of the set of specfiles *you* specified as relevant which is not the set of specfiles that would need modification. So if you say everything here is fruits and there are 10% apples, and I tell you, that we need to count oranges, which is a much higher number, but anyway there are 14% of apples around here, you conclude that I verified that we only need to count apples, and that 14% is the correct number. Don't compare apples and oranges. Hope this analogy makes it clear. > > > Christian said he was 'hardly convinced that represents "almost all > > > specfiles"', and I did a very quick estimation of some numbers, > > > coming up with a figure of about 10% or suggesting that we could > > > push it up to 20% if we calculate differently. Then I accepted your > > > 'correction' of 14%, and you still seem to want to go on about it. > > > > The 14% was a correction of your "we only need to split bins of libs" > > revised model, not the real fact that you need to keep bins everywhere > > in their own sub-subpackage. That's why it's a sub-subpackage. Please > > try reading before replying. > > > > So let's really count the packages that are affected. This involves > > all package that have bins bundled together with something else, not > > only libs, but config files, %lang and %docs. Out of 4468 specfiles > > this affects 2616 which amounts to 59%. > > No, now you've started making stuff up again. The proposal is only that > binary files should conflict. There's no need to make config files, > translations and docs conflict too. Really think this through to the end including your suggested user use cases. Do so, and then check what the bin swapping will cause. Or just read the example below if it doesn't strike you. > You are, again, making stuff up to inflate the numbers -- which is > weird, because the numbers really don't matter anyway. Even if we did > have to touch every specfile in the distro -- like we did to change from > 'Copyright' to 'License' -- if it's the right thing to do then it's the > right thing to do. As I said, we've spent too long taking the easiest > short-term 'solution' for multilib instead of really planning for the > future. And the suggestion to split all bins into sub-sub-packages is just such a easy short-term solution. Even if we magically get the split done or ignore the required man time it o creates file conflicts in the repo by design o thus borks yum, anaconda, smart and apt o Requires users to redownload packages each time they wish to simply switch from foo-32 to foo-64 o Breaks the majority of config files (that's where the 59% come from) > Axel, I really can't be bothered to argue with your hyperbole. My > original figures were close enough to your earlier estimate of 14%; Remember, you apples, me oranges. > > > > o misquoting > > > > > > No, I think you're getting confused again. Every misquote I've seen has > > > been from your side. I really have no need to resort to such tactics -- > > > > But you did, in this very last mail again. I never refered with almost > > all to bins-with-libs packages as you like to present it, and even > > after correcting you as many times, you still present it that way. > > I presented precisely what you said -- your claim that we would need to > "rewrite almost almost all specfiles". In fact, we'd only need a > relatively minor modification to maybe 14% of them. If you allow for your scheme to nuke config files, sure. But that's not what we'd like to have. > That figure only becomes 59% if we take your radical new suggestion of > banning conflicts even in text files, which I suggest we should not do. Then watch how switching from foo-32 to foo-64 undoes the users' config. > I assume you weren't seriously proposing that, and it was just a way to > inflate the numbers some more? I _never_ _ever_ did say that the only thing we would have to do is seperate bins from libs. So this is not something new, for me it was clear from the beginning that your model will have to evolve to sub-sub-packages containing only bins, and I wrote that a miriad times, but you were reading over it. Examples do seem to work better, so let's try once again. # foo # yum remove foo foo is required by bar, baz, barbaz, bazbar, ... [Y,n]: n # rpm -e --nodeps foo /etc/foo.conf is saved as /etc/foo.conf.rpmsave # yum install foo.i386 # foo foo has not been configured # mv /etc/foo.conf.rpmsave # foo So a short-sighted, short term solution once again. you want to do it "right"? You need to make sure the bins don't get packaged together with config files. So that does explode the 14% of just-need-to-split- bins-and-libs to a higher number, right? Not making up anything, just pointing to the flaws of your proposal. > > > The technical side of the conversation stands up on its own. > > > > Indeed. Not only are the amount of packages to adjust to your proposed > > model the majority indeed (59% specfile wise), but your model implies > > file-level conflicts on all these 59% of packages that > > rpm/yum/anaconda/smart/apt will choke on, does not allow coinstalls > > and requires a switch from one arch to another to redownload the > > packages. > > Your 59% is misleading; you changed the rules to get to there from the > 14% you earlier came up with. Not that it matters. Apples and oranges once again. No change of rules, you always read over my posts, why did I say that every subpackage needs to split out the bins into sub-sub-packages from the very beginning? > I cannot speak for smart and apt, but rpm/yum/anaconda certainly don't > have an issue with the existence of multiple packages which provide the > same file -- we have that already, anyway. The above example and all others used yum. And yum does get very angry if there are packages in it's repo-world that conflict on file level. Heck, we even had a guideline rule created exactly for that: Every file conflict needs to be made a package conflict, because yum (rightfully) doesn't like that. And that would not be even possible with your scheme because Conflicts: does not take an arch. So, the proposed sub-subpackaging of bins is flawed from all corners. And the resitance you're feeling from me and seems to make you angry and offensive is just the preview of what rpm and yum maintainers will greet you with once they realize that your scheme needs them to rewrite their tools. No easy short-sighted and short-term solutions was your slogan, stick to it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From n0dalus+redhat at gmail.com Tue May 1 10:09:49 2007 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 1 May 2007 19:39:49 +0930 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <4636CCED.2050304@fedoraproject.org> References: <46311585.20204@redhat.com> <4631976F.6050006@hhs.nl> <4631A0FF.70209@leemhuis.info> <4631AA09.4090805@fedoraproject.org> <20070501043459.GD11331@nostromo.devel.redhat.com> <4636C505.3020104@fedoraproject.org> <20070501050422.GF11331@nostromo.devel.redhat.com> <4636CCED.2050304@fedoraproject.org> Message-ID: <6280325c0705010309sc7755d5vf92d619d44d37da8@mail.gmail.com> On 5/1/07, Rahul Sundaram wrote: > Bill Nottingham wrote: > > If you want to solve the package size issue, switch to presto; > > this would save the download size much more than splitting > > off packages for language packs would. > > I am using it already. Presto only would save sizes on updates. Not the > initial download size or other issues. The bigger problem though is that > Fedora does not have a consistent and documented approach to deal with > language packs throughout the distribution. > +1 Even if we don't end up changing the Firefox package, we need to have some system in place to handle this eventually. While some people may think that the difference it will make to FireFox is not worth it, add that difference up over many packages (including future packages) as Fedora gets larger, and the problem becomes worth solving now. To say that 1MB of RAM/traffic/disk space doesn't count, or 1 second of 3GHz-CPU time is not worth worrying about, is very short sighted IMO. Even if there are bigger savings to be had in other components that are other people's responsibility, don't use that as an excuse to not improve whatever you can. The majority of Fedora and Red Hat developers ostensibly have fast internet connections, big hard drives, DVD readers + burners, fast CPUs and plenty of RAM. Sometimes we need to be reminded that some people only have 128/256MB RAM (when was the last time you tried to boot Fedora with mem=128 ?), a slow CPU, dialup and no dvd drive. Please note, these comments are not to anyone here in particular, so please don't take them as such. I just felt the need to put in my 2c. n0dalus. From mattdm at mattdm.org Tue May 1 11:03:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 1 May 2007 07:03:46 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070501042703.GC11331@nostromo.devel.redhat.com> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> Message-ID: <20070501110346.GA17476@jadzia.bu.edu> On Tue, May 01, 2007 at 12:27:03AM -0400, Bill Nottingham wrote: > - installation of third-party software that is only available for the > secondary arch, in a way that allows it to run How much of this is there in the real world? I mean, we're talking dozens of packages at *most*, right? Matlab, Mathematica, Maple, and Oracle all have 64-bit versions. So in our environment at BU, that leaves Splus (rapidly being displaced by R) and the Flash plugin. And I'm not convinced that the ability to build 32-bit code outside of a chroot is a huge deal either. In five years, that's going to be a really narrow group of users, and do we really want to design our whole system just for that? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pertusus at free.fr Tue May 1 11:18:18 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 1 May 2007 13:18:18 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501093219.GC10108@neu.nirvana> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> Message-ID: <20070501111818.GA24363@free.fr> On Tue, May 01, 2007 at 11:32:19AM +0200, Axel Thimm wrote: > o Breaks the majority of config files (that's where the 59% come from) Are these bugs in packaging or is this solved by the multiarch approach? Do you have examples? -- Pat From katzj at redhat.com Tue May 1 12:34:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 01 May 2007 08:34:25 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070501110346.GA17476@jadzia.bu.edu> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501110346.GA17476@jadzia.bu.edu> Message-ID: <1178022865.13694.24.camel@aglarond.local> On Tue, 2007-05-01 at 07:03 -0400, Matthew Miller wrote: > On Tue, May 01, 2007 at 12:27:03AM -0400, Bill Nottingham wrote: > > - installation of third-party software that is only available for the > > secondary arch, in a way that allows it to run > > How much of this is there in the real world? I mean, we're talking dozens of > packages at *most*, right? Matlab, Mathematica, Maple, and Oracle all have > 64-bit versions. So in our environment at BU, that leaves Splus (rapidly > being displaced by R) and the Flash plugin. There's actually a fair bit of legacy software that falls into this category. And then also various site-specific custom software that was built once and continues to be used to this day. If people didn't want compatibility to run these legacy applications, then they would have bought into Itanium ;-) > And I'm not convinced that the ability to build 32-bit code outside of a > chroot is a huge deal either. In five years, that's going to be a really > narrow group of users, and do we really want to design our whole system just > for that? There's a lot of lower power devices which are still 32-bit only and are going to be for quite a while as far as I can see. And being able to trivially build for them is one of the reasons why you go for x86 for them instead of an embedded specific chip like an arm or a mips. The compatibility and the fact that it's all but entirely transparent is a huge part of the value of the x86->x86_64 transition. Jeremy From Axel.Thimm at ATrpms.net Tue May 1 13:14:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 15:14:14 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501111818.GA24363@free.fr> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <20070501111818.GA24363@free.fr> Message-ID: <20070501131414.GE10108@neu.nirvana> On Tue, May 01, 2007 at 01:18:18PM +0200, Patrice Dumas wrote: > On Tue, May 01, 2007 at 11:32:19AM +0200, Axel Thimm wrote: > > > o Breaks the majority of config files (that's where the 59% come from) > > Are these bugs in packaging No, it is valid to package config files together with binaries. That's in fact the most common packaging for packages that create both bin parts and config files (e.g. devel files get split out into *-devel, sometimes libs get split out in their own package as well, but bins and config files remain in the main package). > or is this solved by the multiarch approach? Yes and no. Yes, because the multiarch design does not require you to uninstall and reinstall bin sub-sub-packages, thus you don't rpmsave your running config and get a fresh one on the arch switching. No, because that bug only exists in the case we would use David's bin sub-sub-packaging proposal. Since we are not using it today, this bug does not exist yet, so there is nothing to solve. This is just a bug which we should not walk into. > Do you have examples? You mean packages that would break that way? Like for example samba, mysql, pam or nss_db? Or any other packages that exists in both x86_64/i386 tandems and have at least on config file? If you want to see what this means on your multilib system try: rpm -qa --qf '%{name}\n' | grep -v ^kernel | grep -v ^gpg-pubkey | sort | uniq -d | xargs rpm -qc | sort -u | xargs rpm -qf | sort -u This lists all multilib packages that share config files on your own system. These packages are already well known because they cause trouble in the current multilib setup due to different mtimes of config files causing one config file set to become rpmsave/rpmnew. And if the target is to have two distinct repos that are both activated, then you can imagine that - since it affects any package that has binary parts and config files - the number is quite high. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue May 1 13:52:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 01 May 2007 14:52:19 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501111818.GA24363@free.fr> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <20070501111818.GA24363@free.fr> Message-ID: <1178027539.2875.71.camel@pmac.infradead.org> On Tue, 2007-05-01 at 13:18 +0200, Patrice Dumas wrote: > On Tue, May 01, 2007 at 11:32:19AM +0200, Axel Thimm wrote: > > > o Breaks the majority of config files (that's where the 59% come from) > > Are these bugs in packaging or is this solved by the multiarch approach? > Do you have examples? It's a fallacy. Any config files which would break are _already_ broken with the existing setup. Please don't feed the trolls. -- dwmw2 From dwmw2 at infradead.org Tue May 1 13:52:39 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 01 May 2007 14:52:39 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501093219.GC10108@neu.nirvana> References: <20070426193041.GB14127@neu.nirvana> <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> Message-ID: <1178027559.2875.73.camel@pmac.infradead.org> I'm not going to bother contradicting you where I've already done so and you're just ignoring what's gone before... On Tue, 2007-05-01 at 11:32 +0200, Axel Thimm wrote: > o thus borks yum, anaconda, smart and apt ... except for this one. Just in _case_ there's anyone left who actually takes your nonsense seriously.... I have a 'testpkg' which provides /usr/bin/foo, in both architectures: pmac /home/dwmw2/bl # rpm -qlp testpkg-1-1.ppc.rpm /usr/bin/foo pmac /home/dwmw2/bl # rpm -qlp testpkg-1-1.ppc64.rpm /usr/bin/foo pmac /home/dwmw2/bl # rpm -Uhv testpkg-1-1.ppc.rpm testpkg-1-1.ppc64.rpm Preparing... ########################################### [100%] 1:testpkg ########################################### [ 50%] 2:testpkg ########################################### [100%] First, we observe that after disabling RPM's multilib behaviour, the two 'testpkg' packages conflict: pmac /home/dwmw2/bl # rpm -e --allmatches testpkg pmac /home/dwmw2/bl # cat /etc/rpm/macros %_transaction_color 3 %_prefer_color 1 pmac /home/dwmw2/bl # gzip /etc/rpm/macros pmac /home/dwmw2/bl # rpm -Uhv testpkg-1-1.ppc.rpm testpkg-1-1.ppc64.rpm warning: package testpkg = 1-1 was already added, skipping testpkg < 1-1 error: error reading from file testpkg-1-1.ppc64.rpm Strange failure mode, but a failure nonetheless -- RPM is not able to install both at once Now, we have a package 'testreq' which requires /usr/bin/foo: pmac /home/dwmw2/bl # rpm -qp --requires testreq-1-1.ppc.rpm | grep bin /usr/bin/foo pmac /home/dwmw2/bl # yum install testreq Loading "skip-broken" plugin Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package testreq.ppc 0:1-1 set to be updated --> Processing Dependency: /usr/bin/foo for package: testreq --> Restarting Dependency Resolution with new changes. --> Running transaction check ---> Package testpkg.ppc 0:1-1 set to be updated Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: testreq ppc 1-1 test 7.0 k Installing for dependencies: testpkg ppc 1-1 test 7.0 k Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 14 k Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: testpkg ######################### [1/2] Installing: testreq ######################### [2/2] Installed: testreq.ppc 0:1-1 Dependency Installed: testpkg.ppc 0:1-1 Complete! Yum did not break. Again, what you say is untrue. -- dwmw2 From ed at eh3.com Tue May 1 14:10:57 2007 From: ed at eh3.com (Ed Hill) Date: Tue, 1 May 2007 10:10:57 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <4636E940.6030801@city-fan.org> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <4635EDFC.9090704@redhat.com> <20070430194603.GF13906@neu.nirvana> <20070430174043.696263de@daggett> <4636E940.6030801@city-fan.org> Message-ID: <20070501101057.154dc90d@daggett> On Tue, 01 May 2007 08:16:16 +0100 Paul Howarth wrote: > Ed Hill wrote: > > On Mon, 30 Apr 2007 21:46:04 +0200 Axel Thimm wrote: > >> Personally I prefer banning multilib in rpm for good and if that > >> would be best done by using chroot solutions, I'm all for it. The > >> multilib implementation within rpm magic just isn't scaling and > >> produces more bugs on the way than we can fix. [snip] > > It just seems to me that chroots are probably a lot less usable than > > binaries placed in {,/usr}/{,s}bin64 or similar. > > chroots and SELinux don't play nicely together at the moment either. > You'd need to replicate the entire set of default contexts into each > chroot. So is it fair to say that chroots are too problematic for anyone other than "extremely knowledgeable users" to take advantage of them? I'm just trying to get across the point that some of the options to {,/usr}/{,s}bin64 that folks have mentioned are probably not all that useful. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Tue May 1 15:59:59 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 1 May 2007 10:59:59 -0500 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070501085835.GB8030@ryvius.pekin.waw.pl> References: <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501085835.GB8030@ryvius.pekin.waw.pl> Message-ID: <20070501155958.GB29958@humbolt.us.dell.com> On Tue, May 01, 2007 at 10:58:36AM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 01 May 2007 at 06:27, Bill Nottingham wrote: > > > > - 32-bit firefox on x86_64, because they need to access content > > only available via proprietary plugins > > We have nspluginwrapper for 64bit firefox. Doesnt work for java. I tried getting latest sun jre running under firefox yesterday and had to resort to 32-bit firefox because nspluginwrapper wouldnt recognize the java plugin. -- Michael From Michael_E_Brown at dell.com Tue May 1 16:03:03 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 1 May 2007 11:03:03 -0500 Subject: using mock for chroot builds. WAS [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070501042703.GC11331@nostromo.devel.redhat.com> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> Message-ID: <20070501160303.GC29958@humbolt.us.dell.com> On Tue, May 01, 2007 at 12:27:03AM -0400, Bill Nottingham wrote: > > - doing development for a non-primary arch without setting up > a chroot. (mock works well for RPMS. mock for random > 'compile this' is a PITA.) What problems do you see with mock, and what kind of suggestions would you make to fix this? -- Michael From dwmw2 at infradead.org Tue May 1 16:06:42 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 01 May 2007 17:06:42 +0100 Subject: using mock for chroot builds. WAS [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <20070501160303.GC29958@humbolt.us.dell.com> References: <20070426092101.GE23704@neu.nirvana> <1177580028.2755.322.camel@pmac.infradead.org> <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501160303.GC29958@humbolt.us.dell.com> Message-ID: <1178035602.2875.86.camel@pmac.infradead.org> On Tue, 2007-05-01 at 11:03 -0500, Michael E Brown wrote: > On Tue, May 01, 2007 at 12:27:03AM -0400, Bill Nottingham wrote: > > > > - doing development for a non-primary arch without setting up > > a chroot. (mock works well for RPMS. mock for random > > 'compile this' is a PITA.) > > What problems do you see with mock, and what kind of suggestions would > you make to fix this? How do I use mock with something other than RPMs? -- dwmw2 From fedora at camperquake.de Tue May 1 16:11:35 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 1 May 2007 18:11:35 +0200 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <46311585.20204@redhat.com> References: <46311585.20204@redhat.com> Message-ID: <20070501181135.4969d83c@lain.camperquake.de> Hi. On Thu, 26 Apr 2007 17:11:33 -0400, Christopher Aillon wrote > On my system right now, /usr/share/locale takes up 373MB, dwarfing > whatever Firefox uses. Splitting out Firefox's langpacks won't solve > your problem. Stupid question: could the .mo files be compressed without changing the way applications access them? From Michael_E_Brown at dell.com Tue May 1 16:11:43 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 1 May 2007 11:11:43 -0500 Subject: using mock for chroot builds. WAS [F8/multilib] {, /usr}/{, s}bin64 In-Reply-To: <1178035602.2875.86.camel@pmac.infradead.org> References: <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501160303.GC29958@humbolt.us.dell.com> <1178035602.2875.86.camel@pmac.infradead.org> Message-ID: <20070501161142.GD29958@humbolt.us.dell.com> On Tue, May 01, 2007 at 05:06:42PM +0100, David Woodhouse wrote: > On Tue, 2007-05-01 at 11:03 -0500, Michael E Brown wrote: > > On Tue, May 01, 2007 at 12:27:03AM -0400, Bill Nottingham wrote: > > > > > > - doing development for a non-primary arch without setting up > > > a chroot. (mock works well for RPMS. mock for random > > > 'compile this' is a PITA.) > > > > What problems do you see with mock, and what kind of suggestions would > > you make to fix this? > > How do I use mock with something other than RPMs? Today (from memory, since it has been a while since I have done this): $ mock init [ -r mockcfg ] This sets up the chroot. Then, you can copy files in and run either 'mock chroot' or 'mock shell' Any suggestions on what you would require to make this process more painless would be appreciated. -- Michael From notting at redhat.com Tue May 1 17:02:17 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 May 2007 13:02:17 -0400 Subject: using mock for chroot builds. WAS [F8/multilib] {, /usr}/{, s}bin64 In-Reply-To: <20070501161142.GD29958@humbolt.us.dell.com> References: <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501160303.GC29958@humbolt.us.dell.com> <1178035602.2875.86.camel@pmac.infradead.org> <20070501161142.GD29958@humbolt.us.dell.com> Message-ID: <20070501170216.GA21885@nostromo.devel.redhat.com> Michael E Brown (Michael_E_Brown at dell.com) said: > Today (from memory, since it has been a while since I have done this): > > $ mock init [ -r mockcfg ] > > This sets up the chroot. Then, you can copy files in and run either > 'mock chroot' or 'mock shell' > > Any suggestions on what you would require to make this process more > painless would be appreciated. I'm not sure. It just seems to compile a random tarball, you either have to have: - a (root) shell open both inside and outside of the chroot or - continually jumping out of the chroot to do mock rpm -Uvh, etc. I don't have any suggestions at the moment - having mock dig through autoconf scripts for dependencies to install doesn't seem right. Bill From notting at redhat.com Tue May 1 17:03:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 1 May 2007 13:03:38 -0400 Subject: [Minimizing Fedora] Langpacks for Firefox. In-Reply-To: <20070501181135.4969d83c@lain.camperquake.de> References: <46311585.20204@redhat.com> <20070501181135.4969d83c@lain.camperquake.de> Message-ID: <20070501170338.GB21885@nostromo.devel.redhat.com> Ralf Ertzinger (fedora at camperquake.de) said: > > On my system right now, /usr/share/locale takes up 373MB, dwarfing > > whatever Firefox uses. Splitting out Firefox's langpacks won't solve > > your problem. > > Stupid question: could the .mo files be compressed without changing the > way applications access them? Would require libc changes, and everything that provides a compressed .mo file would a) need to implicitly require the new libc b) not have anything statically linked that accesses them. Bill From Michael_E_Brown at dell.com Tue May 1 17:06:52 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 1 May 2007 12:06:52 -0500 Subject: using mock for chroot builds. WAS [F8/multilib] {, /usr}/{, s}bin64 In-Reply-To: <20070501170216.GA21885@nostromo.devel.redhat.com> References: <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501160303.GC29958@humbolt.us.dell.com> <1178035602.2875.86.camel@pmac.infradead.org> <20070501161142.GD29958@humbolt.us.dell.com> <20070501170216.GA21885@nostromo.devel.redhat.com> Message-ID: <20070501170651.GE29958@humbolt.us.dell.com> On Tue, May 01, 2007 at 01:02:17PM -0400, Bill Nottingham wrote: > Michael E Brown (Michael_E_Brown at dell.com) said: > > Today (from memory, since it has been a while since I have done this): > > > > $ mock init [ -r mockcfg ] > > > > This sets up the chroot. Then, you can copy files in and run either > > 'mock chroot' or 'mock shell' > > > > Any suggestions on what you would require to make this process more > > painless would be appreciated. > > I'm not sure. It just seems to compile a random tarball, you > either have to have: > > - a (root) shell open both inside and outside of the chroot > > or > > - continually jumping out of the chroot to do mock rpm -Uvh, etc. > > I don't have any suggestions at the moment - having mock dig > through autoconf scripts for dependencies to install doesn't > seem right. Clark and I (the mock maintainers, though Clark is a bit more active than me presently) are on fedora-buildsys list, so if you have suggestions, we would definitely like to hear them. Off the top of my head, how about something like the following (mockup): $ mock init [-r cfg] $ mock copyin [-r cfg] mysoft.tar.gz $ mock installdeps [-r cfg] --manual_deps foo bar baz $ mock shell # ./configure # make Where the last two would be specific to your software. The new commands here are 'copyin' to get your tarball into the chroot, and the '--manual' option for installdeps. -- Michael From tibbs at math.uh.edu Tue May 1 18:29:24 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 May 2007 13:29:24 -0500 Subject: Summary of the 2007-05-01 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-05-01 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070501 Executive summary: No changes have been made to the guidelines this week. Issues pending FESCO ratification: * Two PHP proposals (accepted 5-0): http://fedoraproject.org/wiki/PackagingDrafts/PHP (the first two items only) * Ruby Gems guidelines (accepted 6-0): http://fedoraproject.org/wiki/PackagingDrafts/RubyGems No misc business of note this week. According to recent FESCO policy changes, these notes will not be summarized in the FESCO meeting. Please discuss them here and if there is dissent FESCO can have a vote during the meeting. - J< From Axel.Thimm at ATrpms.net Tue May 1 18:58:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 20:58:54 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1178027539.2875.71.camel@pmac.infradead.org> References: <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <20070501111818.GA24363@free.fr> <1178027539.2875.71.camel@pmac.infradead.org> Message-ID: <20070501185854.GA31325@neu.nirvana> On Tue, May 01, 2007 at 02:52:19PM +0100, David Woodhouse wrote: > On Tue, 2007-05-01 at 13:18 +0200, Patrice Dumas wrote: > > On Tue, May 01, 2007 at 11:32:19AM +0200, Axel Thimm wrote: > > > > > o Breaks the majority of config files (that's where the 59% come from) > > > > Are these bugs in packaging or is this solved by the multiarch approach? > > Do you have examples? > > It's a fallacy. Any config files which would break are _already_ broken > with the existing setup. Please don't feed the trolls. samba and nss_db for example are currently not broken and would break the second you apply your proposal on it. That's a fact, not a fallacy. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue May 1 19:08:27 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 21:08:27 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1178027559.2875.73.camel@pmac.infradead.org> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <1178027559.2875.73.camel@pmac.infradead.org> Message-ID: <20070501190827.GB31325@neu.nirvana> On Tue, May 01, 2007 at 02:52:39PM +0100, David Woodhouse wrote: > I'm not going to bother contradicting you where I've already done so and > you're just ignoring what's gone before... Nice way of eliding the fact that your proposal nukes config files, just to name one established fact, that you generously look over. > On Tue, 2007-05-01 at 11:32 +0200, Axel Thimm wrote: > > o thus borks yum, anaconda, smart and apt > > ... except for this one. Just in _case_ there's anyone left who actually > takes your nonsense seriously.... Nice, you still keep up that adolescent behaviour. Just ask your local rpm/yum representative: Packages with file level conflicts are hell and were the reason the FPC had to make a guideline out of it. But yum maintainers, the FPC and the rest of the world don't see things as clear as D.W., so we should undo guidelines and allow file level conflicts for D.W.'s sake. > Yum did not break. Again, what you say is untrue. yum does not break if it doesn't have to deal with both packages, which may be pulled in by different dependencies. yum is also not a tool for trivial one-package installs, the complexity comes with dependencies, conflicts and multiple package operations. Also whatever conflicts and inter-packages brokenness doesn't show up if you install a single package on a non-conflicting setup. But you probably know that, so do we. Just try the normal user use case, where he will try to install foo.i386 while foo.x86_64 is already installed. "Don't do that!" would be your cure probably, and yumex will paste a backtrace onto the users' screen. Wasn't multilib supposed to improve user experience? ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Tue May 1 20:14:51 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 01 May 2007 21:14:51 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501185854.GA31325@neu.nirvana> References: <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <20070501111818.GA24363@free.fr> <1178027539.2875.71.camel@pmac.infradead.org> <20070501185854.GA31325@neu.nirvana> Message-ID: <1178050491.2875.94.camel@pmac.infradead.org> On Tue, 2007-05-01 at 20:58 +0200, Axel Thimm wrote: > samba and nss_db for example are currently not broken and would break > the second you apply your proposal on it. That's a fact, not a > fallacy. Do elicidate. Not because I think there's even the remotest likelihood that you have a point, but because I find you amusing. -- dwmw2 From dwmw2 at infradead.org Tue May 1 20:19:40 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 01 May 2007 21:19:40 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501190827.GB31325@neu.nirvana> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <1178027559.2875.73.camel@pmac.infradead.org> <20070501190827.GB31325@neu.nirvana> Message-ID: <1178050780.2875.101.camel@pmac.infradead.org> On Tue, 2007-05-01 at 21:08 +0200, Axel Thimm wrote: > But yum maintainers, the FPC and the rest of the world don't see > things as clear as D.W., so we should undo guidelines and allow file > level conflicts for D.W.'s sake. You seem confused -- or deliberately confusing. I'm talking about RPM allowing _fewer_ file conflicts than those we already allow, not more of them. > > Yum did not break. Again, what you say is untrue. > > yum does not break if it doesn't have to deal with both packages, > which may be pulled in by different dependencies. And how might they be pulled in by different dependencies? In practice, not just contrived cases which we wouldn't actually see in Fedora for real? > Just try the normal user use case, where he will try to install > foo.i386 while foo.x86_64 is already installed. "Don't do that!" would > be your cure probably, and yumex will paste a backtrace onto the > users' screen. Wasn't multilib supposed to improve user experience? That is currently (in FC7) not behaving optimally, and the post-F7 multilib plan improves it by getting rid of the mess like bug #235524. When that's done, and it makes sense to _switch_ a package from x86_64 to i386, that isn't hard to support in yum as a single transaction. RPM is already capable of it, of course. -- dwmw2 From Axel.Thimm at ATrpms.net Tue May 1 20:22:47 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 22:22:47 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1178050491.2875.94.camel@pmac.infradead.org> References: <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <20070501111818.GA24363@free.fr> <1178027539.2875.71.camel@pmac.infradead.org> <20070501185854.GA31325@neu.nirvana> <1178050491.2875.94.camel@pmac.infradead.org> Message-ID: <20070501202247.GE31325@neu.nirvana> On Tue, May 01, 2007 at 09:14:51PM +0100, David Woodhouse wrote: > On Tue, 2007-05-01 at 20:58 +0200, Axel Thimm wrote: > > samba and nss_db for example are currently not broken and would break > > the second you apply your proposal on it. That's a fact, not a > > fallacy. > > Do elicidate. Not because I think there's even the remotest likelihood > that you have a point, but because I find you amusing. You already read (over) it. Go up exactly three levels over your own post and be amused. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue May 1 20:37:53 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 May 2007 22:37:53 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1178050780.2875.101.camel@pmac.infradead.org> References: <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <1178027559.2875.73.camel@pmac.infradead.org> <20070501190827.GB31325@neu.nirvana> <1178050780.2875.101.camel@pmac.infradead.org> Message-ID: <20070501203753.GF31325@neu.nirvana> On Tue, May 01, 2007 at 09:19:40PM +0100, David Woodhouse wrote: > On Tue, 2007-05-01 at 21:08 +0200, Axel Thimm wrote: > > But yum maintainers, the FPC and the rest of the world don't see > > things as clear as D.W., so we should undo guidelines and allow file > > level conflicts for D.W.'s sake. > > You seem confused -- or deliberately confusing. I'm talking about RPM > allowing _fewer_ file conflicts than those we already allow, not more of > them. And you are trying to confuse by inspecting parts of your proposal out of the whole context, and discussing about rpm when the flaws are in your proposed packaging scheme. You want to drop multilib support in rpm and I'm all for it, that's not the problem you're looking away from. Have rpm allow no file conflicts, yes, please, I'm backing you up on this (but not for bin sub-sub-packages, but for going multiarch). BUT! You are promoting to have bin sub-sub-packages that *WILL CONFLICT* on a file level. So the rpm manager you just had allow _fewer_ file conflicts will stab your new packaging methods in the back (and rightfully so). Not the removing of multilib support in rpm is bad, but your bin sub-sub-packaging. Still confused? I bet so. > > > Yum did not break. Again, what you say is untrue. > > > > yum does not break if it doesn't have to deal with both packages, > > which may be pulled in by different dependencies. > > And how might they be pulled in by different dependencies? In practice, > not just contrived cases which we wouldn't actually see in Fedora for > real? Like mybrowser.x86_64 requiring java.x86_64 and yourbrowser.i386 requiring java.i386? Real enough? Just add your favourite browser names in the templates. > > Just try the normal user use case, where he will try to install > > foo.i386 while foo.x86_64 is already installed. "Don't do that!" would > > be your cure probably, and yumex will paste a backtrace onto the > > users' screen. Wasn't multilib supposed to improve user experience? > > That is currently (in FC7) not behaving optimally, and the post-F7 > multilib plan improves it by getting rid of the mess like bug #235524. You're comparing apples and bananas now, again. The broken use case refers to your proposed bin sub-sub-packaging w/o any multilib support in rpm and bug #235524 and your comment above to the actuall current setup on rpm multilib bugs. > When that's done, and it makes sense to _switch_ a package from x86_64 > to i386, that isn't hard to support in yum as a single transaction. RPM > is already capable of it, of course. Yeah, sure, you just forget about dependencies, the redownloading of everything (or mega-caching everything that the user needs), and nuking config files. Your proposal needs serious band-aids on every level. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcantrell at redhat.com Tue May 1 20:48:35 2007 From: dcantrell at redhat.com (David Cantrell) Date: Tue, 01 May 2007 16:48:35 -0400 Subject: Buildsystem / CVS outage for the merger In-Reply-To: <200704301423.20451.jkeating@redhat.com> References: <200704301423.20451.jkeating@redhat.com> Message-ID: <1178052515.21796.19.camel@mortise.boston.redhat.com> On Mon, 2007-04-30 at 14:23 -0700, Jesse Keating wrote: > We're going to give the merger another go this Wed. This will require the > buildsystem(s) to be offline as well as CVS during the merge process. We are > targetting Wed 12:00pm EDT as the outage time (that's Noon). > > See http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge for details. I might be alone in this, but doing the merge now sounds like a bad idea. It didn't happen and we are frozen now for critical bug fixes for F7. Merging now sounds like too many opportunities for badness right on the edge of releasing F7. -- David Cantrell Red Hat / Westford, MA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue May 1 21:12:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 1 May 2007 17:12:20 -0400 Subject: Buildsystem / CVS outage for the merger In-Reply-To: <1178052515.21796.19.camel@mortise.boston.redhat.com> References: <200704301423.20451.jkeating@redhat.com> <1178052515.21796.19.camel@mortise.boston.redhat.com> Message-ID: <200705011712.21014.jkeating@redhat.com> On Tuesday 01 May 2007 16:48:35 David Cantrell wrote: > I might be alone in this, but doing the merge now sounds like a bad > idea. ?It didn't happen and we are frozen now for critical bug fixes for > F7. ?Merging now sounds like too many opportunities for badness right on > the edge of releasing F7. The release team and the board considered this, however we are keeping careful eye on what package builds will actually get tagged for the final release. We also kicked out the deep freeze date a week to give more slush time. The overall major goal with F7 was the merger, so we're accepting the extra risk in order to make good on our goal. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From williams at redhat.com Tue May 1 21:30:26 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 01 May 2007 16:30:26 -0500 Subject: using mock for chroot builds. WAS [F8/multilib] {, /usr}/{, s}bin64 In-Reply-To: <20070501170651.GE29958@humbolt.us.dell.com> References: <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501160303.GC29958@humbolt.us.dell.com> <1178035602.2875.86.camel@pmac.infradead.org> <20070501161142.GD29958@humbolt.us.dell.com> <20070501170216.GA21885@nostromo.devel.redhat.com> <20070501170651.GE29958@humbolt.us.dell.com> Message-ID: <4637B172.8090108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Tue, May 01, 2007 at 01:02:17PM -0400, Bill Nottingham wrote: >> Michael E Brown (Michael_E_Brown at dell.com) said: >>> Today (from memory, since it has been a while since I have done this): >>> >>> $ mock init [ -r mockcfg ] >>> >>> This sets up the chroot. Then, you can copy files in and run either >>> 'mock chroot' or 'mock shell' >>> >>> Any suggestions on what you would require to make this process more >>> painless would be appreciated. >> I'm not sure. It just seems to compile a random tarball, you >> either have to have: >> >> - a (root) shell open both inside and outside of the chroot >> >> or >> >> - continually jumping out of the chroot to do mock rpm -Uvh, etc. >> >> I don't have any suggestions at the moment - having mock dig >> through autoconf scripts for dependencies to install doesn't >> seem right. > > Clark and I (the mock maintainers, though Clark is a bit more active > than me presently) are on fedora-buildsys list, so if you have > suggestions, we would definitely like to hear them. > > Off the top of my head, how about something like the following (mockup): > > $ mock init [-r cfg] > $ mock copyin [-r cfg] mysoft.tar.gz > $ mock installdeps [-r cfg] --manual_deps foo bar baz > $ mock shell > > # ./configure > # make > > Where the last two would be specific to your software. The new commands > here are 'copyin' to get your tarball into the chroot, and the > '--manual' option for installdeps. > > -- > Michael > That looks like a good start. Should we provide a non-root shell option in the chroot or is that just complicating things too much? Something like: $ mock -r cfg shell --nonroot We could automagically set the UID to be mockbuild and start the user off in the builddir directory. Probably would want to set the PS1 to reflect who we are; currently it's set to "mock-chroot> ", but you're uid=0 and gid is mockbuild. Dunno whether that would be useful or just more cruft we'd have to lug along. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGN7FyHyuj/+TTEp0RAi9QAJ0SMgIK1naiGgP7Pg2HxSZrdLUj7gCfckXQ r2J33syevT/dtfa4kQ+MKMQ= =2V+Y -----END PGP SIGNATURE----- From skvidal at linux.duke.edu Tue May 1 21:47:44 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 01 May 2007 17:47:44 -0400 Subject: using mock for chroot builds. WAS [F8/multilib] {, /usr}/{, s}bin64 In-Reply-To: <4637B172.8090108@redhat.com> References: <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501160303.GC29958@humbolt.us.dell.com> <1178035602.2875.86.camel@pmac.infradead.org> <20070501161142.GD29958@humbolt.us.dell.com> <20070501170216.GA21885@nostromo.devel.redhat.com> <20070501170651.GE29958@humbolt.us.dell.com> <4637B172.8090108@redhat.com> Message-ID: <1178056064.18256.22.camel@cutter> On Tue, 2007-05-01 at 16:30 -0500, Clark Williams wrote: > That looks like a good start. > > Should we provide a non-root shell option in the chroot or is that just > complicating things too much? Something like: > > $ mock -r cfg shell --nonroot > > We could automagically set the UID to be mockbuild and start the user > off in the builddir directory. Probably would want to set the PS1 to > reflect who we are; currently it's set to "mock-chroot> ", but you're > uid=0 and gid is mockbuild. > > Dunno whether that would be useful or just more cruft we'd have to lug > along. I kinda think it would be more cruft to lug around. That doesn't mean it wouldn't be useful just that it might not be useful ENOUGH. -sv From bnocera at redhat.com Tue May 1 22:06:45 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 01 May 2007 23:06:45 +0100 Subject: Buildsystem / CVS outage for the merger In-Reply-To: <200705011712.21014.jkeating@redhat.com> References: <200704301423.20451.jkeating@redhat.com> <1178052515.21796.19.camel@mortise.boston.redhat.com> <200705011712.21014.jkeating@redhat.com> Message-ID: <1178057205.3158.81.camel@cookie.hadess.net> On Tue, 2007-05-01 at 17:12 -0400, Jesse Keating wrote: > On Tuesday 01 May 2007 16:48:35 David Cantrell wrote: > > I might be alone in this, but doing the merge now sounds like a bad > > idea. It didn't happen and we are frozen now for critical bug fixes for > > F7. Merging now sounds like too many opportunities for badness right on > > the edge of releasing F7. > > The release team and the board considered this, however we are keeping careful > eye on what package builds will actually get tagged for the final release. > We also kicked out the deep freeze date a week to give more slush time. The > overall major goal with F7 was the merger, so we're accepting the extra risk > in order to make good on our goal. We have a good bunch of bugs that are waiting on the merge to add features/fix bugs. Eg. I'd like Rhythmbox to be able to tag MP3 files, Totem to play VCDs, and HAL should be rebuilt to be able to change the brightness on Dell laptops. We've been waiting for the merge to fix those bugs (the merge should have happened while we weren't frozen, IIRC), otherwise, we'd have moved some of those packages in core to be able to get this functionality. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236775 From bpepple at fedoraproject.org Tue May 1 20:58:20 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 01 May 2007 16:58:20 -0400 Subject: FESCo Meeting Summary for 2007-04-26 Message-ID: <1178053100.5948.7.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Rex Dieter (rdieter) * Jesse Keating (f13) * Christian Iseli (c4chris) * Toshio Kuratomi (abadger1999) * Josh Boyer (jwb) * Jeremy Katz (jeremy) * Bill Nottingham (notting) * Warren Togami (warren) === Members Absent === * Dennis Gilmore (dgilmore) * Kevin Fenzi (nirik) * Tom Callaway (spot) === Summary === == FESCo Meeting Minutes == * warren will look at a bot to post irc logs from the meeting to a web directory, and then we will only be posting the summaries to the wiki. == Policies Updating == * c4chris, tibbs, and bpepple will start fixing policies that have inconsistencies due to the merging of Core & Extras. == Sub-Groups Reporting to FESCo == * Discussed how to be more efficient in handling of reporting from sub-groups. If a sub-groups provides a summary 24-hours prior to the FESCo meeting, the FESCo chair will just ask if there are "any objection to this week's report of at ". The consensus was that there was no need to go over items that people didn't object to. * Still needs to decide procedure for summaries from groups that can't get a summary to FESCo in time. bpepple sent an e-mail to the mailing list to get input on how folks would like to handle this. https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070426 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Wed May 2 07:43:02 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 02 May 2007 08:43:02 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501202247.GE31325@neu.nirvana> References: <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <20070501111818.GA24363@free.fr> <1178027539.2875.71.camel@pmac.infradead.org> <20070501185854.GA31325@neu.nirvana> <1178050491.2875.94.camel@pmac.infradead.org> <20070501202247.GE31325@neu.nirvana> Message-ID: <1178091782.2875.162.camel@pmac.infradead.org> On Tue, 2007-05-01 at 22:22 +0200, Axel Thimm wrote: > You already read (over) it. Go up exactly three levels over your own > post and be amused. Oh, I see. You're talking about the mtime bug and pretending it's a problem with splitting packages. Yes, including mtime as a criterion when deciding if files are 'identical' was a mistake from the beginning, and should be fixed. Isn't there a bug filed for that already? There is a coherent plan for fixing multilib in F8 -- it's not _just_ a matter of fixing the packages which contain both binaries and executables. Fixing the mtime bug in RPM should be part of that plan. -- dwmw2 From dwmw2 at infradead.org Wed May 2 07:50:11 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 02 May 2007 08:50:11 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501203753.GF31325@neu.nirvana> References: <200704271309.43597.jkeating@redhat.com> <1177695416.2755.624.camel@pmac.infradead.org> <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <1178027559.2875.73.camel@pmac.infradead.org> <20070501190827.GB31325@neu.nirvana> <1178050780.2875.101.camel@pmac.infradead.org> <20070501203753.GF31325@neu.nirvana> Message-ID: <1178092211.2875.170.camel@pmac.infradead.org> On Tue, 2007-05-01 at 22:37 +0200, Axel Thimm wrote: > BUT! You are promoting to have bin sub-sub-packages that *WILL > CONFLICT* on a file level. So the rpm manager you just had allow > _fewer_ file conflicts will stab your new packaging methods in the > back (and rightfully so). You repeat this falsehood _despite_ the fact that there would be no more file conflicts in the repository than there are right now, and the fact that I showed an example of yum coping with it just fine? > Like mybrowser.x86_64 requiring java.x86_64 and yourbrowser.i386 > requiring java.i386? Real enough? Just add your favourite browser > names in the templates. If it's in a separate process it shouldn't matter about wordsize. I believe (although I could be wrong) that konqueror uses an external 'java' process and works OK when that's of a different arch. I suspect you're thinking of the case where it's actually a library, and has to be dlopened by the the browser. In which case you're being deliberately misleading again (or just stupid), and you miss the point that it would have to be 'java-libs.i386' and 'java-libs.x86_64', and they'd install in parallel just fine. You're making less and less sense as time goes on -- you've lost what little credibility you already had, and I really can't be bothered to deal with your idiocy any more. Goodbye. *plonk* -- dwmw2 From Axel.Thimm at ATrpms.net Wed May 2 08:38:08 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 2 May 2007 10:38:08 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1178091782.2875.162.camel@pmac.infradead.org> References: <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <20070501111818.GA24363@free.fr> <1178027539.2875.71.camel@pmac.infradead.org> <20070501185854.GA31325@neu.nirvana> <1178050491.2875.94.camel@pmac.infradead.org> <20070501202247.GE31325@neu.nirvana> <1178091782.2875.162.camel@pmac.infradead.org> Message-ID: <20070502083808.GG9228@neu.nirvana> On Wed, May 02, 2007 at 08:43:02AM +0100, David Woodhouse wrote: > On Tue, 2007-05-01 at 22:22 +0200, Axel Thimm wrote: > > You already read (over) it. Go up exactly three levels over your own > > post and be amused. > > Oh, I see. You're talking about the mtime bug and pretending it's a > problem with splitting packages. No, no relation to the mtime bug. I now really need to think whether you don't want to read or can't read the relevant parts. Neither is really an improvement, so it probably doesn't matter. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Wed May 2 08:43:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 2 May 2007 10:43:19 +0200 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <1178092211.2875.170.camel@pmac.infradead.org> References: <20070427182256.GG3831@neu.nirvana> <1177700868.2755.655.camel@pmac.infradead.org> <20070428131521.GA4926@neu.nirvana> <1177774282.2831.84.camel@pmac.infradead.org> <20070501093219.GC10108@neu.nirvana> <1178027559.2875.73.camel@pmac.infradead.org> <20070501190827.GB31325@neu.nirvana> <1178050780.2875.101.camel@pmac.infradead.org> <20070501203753.GF31325@neu.nirvana> <1178092211.2875.170.camel@pmac.infradead.org> Message-ID: <20070502084319.GH9228@neu.nirvana> On Wed, May 02, 2007 at 08:50:11AM +0100, David Woodhouse wrote: > On Tue, 2007-05-01 at 22:37 +0200, Axel Thimm wrote: > > BUT! You are promoting to have bin sub-sub-packages that *WILL > > CONFLICT* on a file level. So the rpm manager you just had allow > > _fewer_ file conflicts will stab your new packaging methods in the > > back (and rightfully so). > > You repeat this falsehood _despite_ the fact that there would be no more > file conflicts in the repository than there are right now, but now they are dealt with > and the fact that I showed an example of yum coping with it just > fine? Oh, I can show you many examples of yum coping with a package against which 1000 other packages conflict on package/file and implicit levels. That doesn't mean that yum won't get rightfully upset once it need to look at more than one package ... > > Like mybrowser.x86_64 requiring java.x86_64 and yourbrowser.i386 > > requiring java.i386? Real enough? Just add your favourite browser > > names in the templates. > > If it's in a separate process it shouldn't matter about wordsize. yum install mybrowser.x86_64 yourbrowser.i386 resolving dependencies ... ... file /usr/bin/xxx from java.x86_64 conflicts with filr /usr/bin/xxx from java.i386 > I suspect you're thinking of the case where it's actually a library, and > has to be dlopened by the the browser. In which case you're being > deliberately misleading again (or just stupid), and you miss the point > that it would have to be 'java-libs.i386' and 'java-libs.x86_64', and > they'd install in parallel just fine. Come on David, every time you reach the end of your arguments you have to become offensively insultive. That just proves that once again your chain of arguments ended in /dev/null. > You're making less and less sense as time goes on -- you've lost what > little credibility you already had, and I really can't be bothered to > deal with your idiocy any more. Goodbye. > > *plonk* Have fun in the bin, I'm not going to drag you out of there again. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwmw2 at infradead.org Wed May 2 15:23:48 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 02 May 2007 16:23:48 +0100 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <200704261322.01077.jkeating@redhat.com> References: <200704261322.01077.jkeating@redhat.com> Message-ID: <1178119428.11120.38.camel@pmac.infradead.org> On Thu, 2007-04-26 at 13:22 -0400, Jesse Keating wrote: > Fill in your suggestion for the blanks. Cannot link to Zod in the > same way that Zod is linked to Bordeaux. > > Suggestions will be ran through the legal queue and an election will happen > for Fedora contributors to pick the next Fedora name. 09F911029D74E35BD84156C5635688C0 I'm not entirely sure what the link is but I'll buy a beer for the first person providing an appropriate one :) -- dwmw2 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From icon at fedoraproject.org Wed May 2 15:27:01 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 2 May 2007 11:27:01 -0400 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1178119428.11120.38.camel@pmac.infradead.org> References: <200704261322.01077.jkeating@redhat.com> <1178119428.11120.38.camel@pmac.infradead.org> Message-ID: On 5/2/07, David Woodhouse wrote: > I'm not entirely sure what the link is but I'll buy a beer for the first > person providing an appropriate one :) Villains bent on world domination. :) -- Konstantin Ryabitsev Montr?al, Qu?bec From jkeating at redhat.com Wed May 2 16:11:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 May 2007 09:11:12 -0700 Subject: Buildsystem / CVS outage for the merger In-Reply-To: <200704301423.20451.jkeating@redhat.com> References: <200704301423.20451.jkeating@redhat.com> Message-ID: <200705020911.12838.jkeating@redhat.com> On Monday 30 April 2007 14:23:20 Jesse Keating wrote: > We're going to give the merger another go this Wed. This will require the > buildsystem(s) to be offline as well as CVS during the merge process. We > are targetting Wed 12:00pm EDT as the outage time (that's Noon). > > See http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge for > details. Outage has begun. Builds that were already started should finish, but the tag step may fail. I'll try to watch for those and tag them forcefully. Will report later how progress goes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Wed May 2 16:19:31 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 02 May 2007 17:19:31 +0100 Subject: [F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl) In-Reply-To: <20070501101057.154dc90d@daggett> References: <20070427151007.GA3831@neu.nirvana> <1177691703.2755.616.camel@pmac.infradead.org> <20070427173215.GD3831@neu.nirvana> <20070427181435.GC23643@ryvius.pekin.waw.pl> <20070427182939.GH3831@neu.nirvana> <20070427184203.GE23643@ryvius.pekin.waw.pl> <20070428112240.GB2187@neu.nirvana> <20070429171838.GA6503@ryvius.pekin.waw.pl> <20070430115355.GC13906@neu.nirvana> <4635EDFC.9090704@redhat.com> <20070430194603.GF13906@neu.nirvana> <20070430174043.696263de@daggett> <4636E940.6030801@city-fan.org> <20070501101057.154dc90d@daggett> Message-ID: <1178122771.4249.28.camel@metropolis.intra.city-fan.org> On Tue, 2007-05-01 at 10:10 -0400, Ed Hill wrote: > On Tue, 01 May 2007 08:16:16 +0100 Paul Howarth wrote: > > > Ed Hill wrote: > > > On Mon, 30 Apr 2007 21:46:04 +0200 Axel Thimm wrote: > > >> Personally I prefer banning multilib in rpm for good and if that > > >> would be best done by using chroot solutions, I'm all for it. The > > >> multilib implementation within rpm magic just isn't scaling and > > >> produces more bugs on the way than we can fix. > > [snip] > > > > It just seems to me that chroots are probably a lot less usable than > > > binaries placed in {,/usr}/{,s}bin64 or similar. > > > > chroots and SELinux don't play nicely together at the moment either. > > You'd need to replicate the entire set of default contexts into each > > chroot. > > > So is it fair to say that chroots are too problematic for anyone other > than "extremely knowledgeable users" to take advantage of them? >From an SELinux point of view, probably yes at the moment. Consider the two chroot environments I currently use: 1. bind-chroot. The selinux-policy replicates the default contents for everything under /var/named/chroot: # semanage fcontext -l | grep chroot /var/named/chroot(/.*)? all files system_u:object_r:named_conf_t:s0 /var/named/chroot/etc(/.*)? all files system_u:object_r:named_conf_t:s0 /var/named/chroot/var/tmp(/.*)? all files system_u:object_r:named_cache_t:s0 /var/named/chroot/var/named(/.*)? all files system_u:object_r:named_zone_t:s0 /var/named/chroot/var/run/dbus(/.*)? all files system_u:object_r:system_dbusd_var_run_t:s0 /var/named/chroot/var/run/named.* all files system_u:object_r:named_var_run_t:s0 /var/named/chroot/var/named/data(/.*)? all files system_u:object_r:named_cache_t:s0 /var/named/chroot/var/named/slaves(/.*)? all files system_u:object_r:named_cache_t:s0 /var/named/chroot/dev/null character device system_u:object_r:null_device_t:s0 /var/named/chroot/dev/zero character device system_u:object_r:zero_device_t:s0 /var/named/chroot/dev/random character device system_u:object_r:random_device_t:s0 /var/named/chroot/etc/rndc\.key regular file system_u:object_r:dnssec_t:s0 /var/named/chroot/var/named/named\.ca regular file system_u:object_r:named_conf_t:s0 This is manageable because there are only a very limited number of types of files living in this chroot, and only one application using them. 2. mock This is a much more complicated issue because just about anything might need to run as part of a package build within a mock chroot, and the path to the chroot includes an arbitrary directory name, albeit fixed to be within /var/lib/mock. The current method for using mock with SELinux enforcing effectively runs the entire build process unconfined by SELinux, since it would be too complicated to get the file contexts set up "properly". A possible solution to this could involve rpm looking up the file contexts for files it's about to install based on their pathname within the chroot rather than their full hierarchical pathname from the real root directory; I don't know enough about rpm internals to know if that's viable though. That would get the initial contexts right but there would still be problems if the system was relabelled though, unless the relabelling process could be made aware of the chroots and treat them accordingly. Paul. From buildsys at fedoraproject.org Wed May 2 18:22:50 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 2 May 2007 14:22:50 -0400 (EDT) Subject: Package EVR problems in FC+FE 2007-05-02 Message-ID: <20070502182250.3ABB9152131@buildsys.fedoraproject.org> cbalint AT redhat.com: iverilog FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) limb AT jcomserv.net: gnubg FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) pertusus AT free.fr: dap-server FE6 > FE7 (0:3.7.4-2.fc6 > 0:3.7.1-4.fc7) vcrhonek AT redhat.com: m4 FC6-updates > FC7 (0:1.4.8-2 > 0:1.4.8-1) ---------------------------------------------------------------------- dap-server: pertusus AT free.fr FE6 > FE7 (0:3.7.4-2.fc6 > 0:3.7.1-4.fc7) gnubg: limb AT jcomserv.net FE5 > FE7 (0:20061119-11.fc5 > 0:20061119-7.fc7) FE6 > FE7 (0:20061119-11.fc6 > 0:20061119-7.fc7) iverilog: cbalint AT redhat.com FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) m4: vcrhonek AT redhat.com FC6-updates > FC7 (0:1.4.8-2 > 0:1.4.8-1) From wart at kobold.org Wed May 2 19:07:32 2007 From: wart at kobold.org (Michael Thomas) Date: Wed, 02 May 2007 12:07:32 -0700 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177613624.15366.52.camel@localhost.localdomain> References: <200704261322.01077.jkeating@redhat.com> <1177613624.15366.52.camel@localhost.localdomain> Message-ID: <4638E174.7060200@kobold.org> Callum Lerwick wrote: > On Thu, 2007-04-26 at 13:22 -0400, Jesse Keating wrote: >> Fill in your suggestion for the blanks. Cannot link to Zod in the >> same way that Zod is linked to Bordeaux. > > Zod is a General, and the core/extras merge is general chaos, so Fedora > 7 = Chaos? I thought it was Captain Chaos and General Disarray? --Wart From bpepple at fedoraproject.org Wed May 2 19:15:17 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 May 2007 15:15:17 -0400 Subject: Plan for tomorrows (20070503) FESCO meeting Message-ID: <1178133317.17387.10.camel@lincoln> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00507.html /topic FESCO-Meeting -- MISC -- Meeting Minutes IRC bot -- warren /topic FESCO-Meeting -- MISC -- EPEL Reporting - https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- Fedora 7 preparation (merge, etc) /topic FESCO-Meeting -- MISC -- Policies that need updating for merge update -- http://fedoraproject.org/wiki/PackageMaintainers/Policy /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Wed May 2 21:34:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 03 May 2007 03:04:39 +0530 Subject: Plan for tomorrows (20070503) FESCO meeting In-Reply-To: <1178133317.17387.10.camel@lincoln> References: <1178133317.17387.10.camel@lincoln> Message-ID: <463903EF.9060206@fedoraproject.org> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: > > /topic FESCo meeting -- Any objection to this week's report from FPC at > https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00507.html > > /topic FESCO-Meeting -- MISC -- Meeting Minutes IRC bot -- warren > > /topic FESCO-Meeting -- MISC -- EPEL Reporting - > https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > /topic FESCO-Meeting -- MISC -- Fedora 7 preparation (merge, etc) > > /topic FESCO-Meeting -- MISC -- Policies that need updating for merge > update -- http://fedoraproject.org/wiki/PackageMaintainers/Policy > > /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. > Might be worth considering whether we want to do another test release after the merge considering that there are still a number of bugs that look critical flowing in via test list and bugzilla and desktop team has been waiting on the merge to enable some features. Atleast a more public release candidate would be appropriate I think. Rahul From jkeating at redhat.com Wed May 2 22:04:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 May 2007 15:04:31 -0700 Subject: Status of the merge Message-ID: <200705021504.34910.jkeating@redhat.com> Merge is going well now. A bunch of hiccups early on as we moved our test scripts into acting with real bits and databases and such, but now that that's over... Current extras package owners and packages from owners.list have been imported into koji, for the fe7-merge tag (a staging tag I'm using in case something goes wrong and we have to start over). Content from Core cvs is being merged with content from Extras CVS in a new cvs root. This process will take quite a while and generate a lot of email. Sorry. The latest Core packages have been synced, a few more will be synced tomorrow as the builds that were in progress when we started the outage are tagged if necessary. The latest Extras builds for development are currently being imported into koji. This will take a long time too, but thankfully no email should be generated. These tasks are likely to take through the night, and given such, I expect most of us will try to get a good nights sleep for the uphill battle that will come tomorrow when we try to hook up and turn all of this back on for developers to use. A document about the new layout/procedure is underway and should be finished at some point tomorrow. For those interested, here are some reference items: http://koji.fedoraproject.org/koji ( The main koji web interface ) http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge ( overall topic and status ) http://fedoraproject.org/wiki/Infrastructure/CoreExtrasCVSMerge ( specific to the CVS merge ) Thank you for all your patience as we try to make this dream come true! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed May 2 22:22:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 May 2007 18:22:43 -0400 Subject: Status of the merge In-Reply-To: <200705021504.34910.jkeating@redhat.com> References: <200705021504.34910.jkeating@redhat.com> Message-ID: <20070502222243.GA32656@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > Content from Core cvs is being merged with content from Extras CVS in a new > cvs root. This process will take quite a while and generate a lot of email. > Sorry. Upon seeing the content of these mails, it was obvious that due to how content was being copied, the mails didn't (and couldn't) actually have any useful content in them. As they also slowed down the import process tremendously, it's been shut off. This cuts down the import time for a package from ~35 seconds to 5-10 seconds. Bill From roland at redhat.com Wed May 2 22:39:52 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 2 May 2007 15:39:52 -0700 (PDT) Subject: Status of the merge In-Reply-To: Bill Nottingham's message of Wednesday, 2 May 2007 18:22:43 -0400 <20070502222243.GA32656@nostromo.devel.redhat.com> Message-ID: <20070502223952.1F1761801A3@magilla.sf.frob.com> The useless email I got made it look like extras/foo/devel/Makefile was getting fresh boilerplate, not copying dist/foo/devel/Makefile. Is this going to lose custom Core devel/Makefile or FC-*/Makefile contents that had a superset of the old /cvs/dist boilerplate Makefile functionality? Thanks, Roland From bpepple at fedoraproject.org Wed May 2 22:43:50 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 May 2007 18:43:50 -0400 Subject: Plan for tomorrows (20070503) FESCO meeting In-Reply-To: <463903EF.9060206@fedoraproject.org> References: <1178133317.17387.10.camel@lincoln> <463903EF.9060206@fedoraproject.org> Message-ID: <1178145830.5872.1.camel@lincoln> On Thu, 2007-05-03 at 03:04 +0530, Rahul Sundaram wrote: > Might be worth considering whether we want to do another test release > after the merge considering that there are still a number of bugs that > look critical flowing in via test list and bugzilla and desktop team has > been waiting on the merge to enable some features. > > Atleast a more public release candidate would be appropriate I think. I'll bring this up tomorrow, since we'll be talking about a bunch of issues in regard to the merge. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed May 2 22:42:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 May 2007 15:42:47 -0700 Subject: Status of the merge In-Reply-To: <20070502223952.1F1761801A3@magilla.sf.frob.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> Message-ID: <200705021542.47760.jkeating@redhat.com> On Wednesday 02 May 2007 15:39:52 Roland McGrath wrote: > The useless email I got made it look like extras/foo/devel/Makefile was > getting fresh boilerplate, not copying dist/foo/devel/Makefile. ?Is this > going to lose custom Core devel/Makefile or FC-*/Makefile contents that had > a superset of the old /cvs/dist boilerplate Makefile functionality? Yes, cvs.fedora Makefile.common diverged from Red Hat's internal Makefile.common. Much in RH's doesn't make sense in Fedora's, but some does. If you find functionality missing, please request specific things get added in. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Wed May 2 22:57:38 2007 From: roland at redhat.com (Roland McGrath) Date: Wed, 2 May 2007 15:57:38 -0700 (PDT) Subject: Status of the merge In-Reply-To: Jesse Keating's message of Wednesday, 2 May 2007 15:42:47 -0700 <200705021542.47760.jkeating@redhat.com> Message-ID: <20070502225738.AA4F11801A3@magilla.sf.frob.com> > Yes, cvs.fedora Makefile.common diverged from Red Hat's internal > Makefile.common. Much in RH's doesn't make sense in Fedora's, but some > does. If you find functionality missing, please request specific things > get added in. I'm talking about package-specific stuff package maintainers have put in their own Makefile. Everything I'm aware of lets Makefile.common do whatever it does, and just adds some things that the maintainers also use. If maintainers have to recover all their Makefile bits by hand from the old history, that's not the end of the world. It would be better if they at least got told about it explicitly for each Makefile that didn't match the old vanilla boilerplate verbatim. I'm now suddenly wondering if you might be doing something completely insane. The message I got kind of made it sound like fresh stuff was being added. As if you imported files with fresh cvs commits. Instead of copying the old repository directories from /cvs/dist to /cvs/extras with their RCS files completely intact, so that every developer's existing checkout can be salvaged just by diddling CVS/Root (and worst case CVS/Repository) files. If you did that, I might just have to launch my doomsday weapon and end it all. Thanks, Roland From jwboyer at jdub.homelinux.org Thu May 3 00:36:56 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 02 May 2007 19:36:56 -0500 Subject: Plan for tomorrows (20070503) FESCO meeting In-Reply-To: <463903EF.9060206@fedoraproject.org> References: <1178133317.17387.10.camel@lincoln> <463903EF.9060206@fedoraproject.org> Message-ID: <1178152616.3571.4.camel@vader.jdub.homelinux.org> On Thu, 2007-05-03 at 03:04 +0530, Rahul Sundaram wrote: > Brian Pepple wrote: > > Hi, > > > > Please find below the list of topics that are likely to come up in the > > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > > in #fedora-meeting on irc.freenode.org: > > > > /topic FESCo meeting -- Any objection to this week's report from FPC at > > https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00507.html > > > > /topic FESCO-Meeting -- MISC -- Meeting Minutes IRC bot -- warren > > > > /topic FESCO-Meeting -- MISC -- EPEL Reporting - > > https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html > > > > /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 > > > > /topic FESCO-Meeting -- MISC -- Fedora 7 preparation (merge, etc) > > > > /topic FESCO-Meeting -- MISC -- Policies that need updating for merge > > update -- http://fedoraproject.org/wiki/PackageMaintainers/Policy > > > > /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb > > > > /topic FESCo meeting -- Free discussion around Fedora > > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > > > Might be worth considering whether we want to do another test release > after the merge considering that there are still a number of bugs that > look critical flowing in via test list and bugzilla and desktop team has > been waiting on the merge to enable some features. Do you happen to have a list of these bugs somewhere? Or Will, do you? josh From notting at redhat.com Thu May 3 02:31:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 May 2007 22:31:10 -0400 Subject: Status of the merge In-Reply-To: <20070502225738.AA4F11801A3@magilla.sf.frob.com> References: <200705021542.47760.jkeating@redhat.com> <20070502225738.AA4F11801A3@magilla.sf.frob.com> Message-ID: <20070503023110.GA3027@nostromo.devel.redhat.com> Roland McGrath (roland at redhat.com) said: > I'm now suddenly wondering if you might be doing something completely insane. > The message I got kind of made it sound like fresh stuff was being added. As > if you imported files with fresh cvs commits. Instead of copying the old > repository directories from /cvs/dist to /cvs/extras with their RCS files > completely intact, so that every developer's existing checkout can be > salvaged just by diddling CVS/Root (and worst case CVS/Repository) files. > If you did that, I might just have to launch my doomsday weapon and end it all. First, a fresh import was done. That generated said mail. Then, the current contents were added. As that's not a CVS operation, that generated no mail; hence, having mail on seemed pointless. Bill From sundaram at fedoraproject.org Thu May 3 03:29:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 03 May 2007 08:59:40 +0530 Subject: Plan for tomorrows (20070503) FESCO meeting In-Reply-To: <1178152616.3571.4.camel@vader.jdub.homelinux.org> References: <1178133317.17387.10.camel@lincoln> <463903EF.9060206@fedoraproject.org> <1178152616.3571.4.camel@vader.jdub.homelinux.org> Message-ID: <46395724.4090201@fedoraproject.org> Josh Boyer wrote: > On Thu, 2007-05-03 at 03:04 +0530, Rahul Sundaram wrote: >>> >> Might be worth considering whether we want to do another test release >> after the merge considering that there are still a number of bugs that >> look critical flowing in via test list and bugzilla and desktop team has >> been waiting on the merge to enable some features. > > Do you happen to have a list of these bugs somewhere? Or Will, do you? > Not a handy list of bug reports but there are some ongoing discussions in fedora-test list which does not give me any confidence. The libata changes have rendered some (many?) systems unbootable and some people in the Fedora forum who have been trying out all the F7 test releases have yet to get their system to boot. I did ask them to report bugs but all of them might not be currently tracked in QA. https://www.redhat.com/archives/fedora-test-list/2007-April/msg00566.html https://www.redhat.com/archives/fedora-test-list/2007-April/msg00620.html https://www.redhat.com/archives/fedora-test-list/2007-April/msg00690.html Recent kernels seems to have regressions - ethernet, sound cards not working etc. Of course this is the test list and it never paints a rosy picture but I think we should do a test release of the merged tree. Desktop team and KDE SIG have been waiting for the merge to do some fairly important changes. If we are you might consider a mass rebuild of packages with disttags too. Someone closer to development and QA might have a better idea. Rahul From jkeating at redhat.com Thu May 3 04:05:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 May 2007 21:05:16 -0700 Subject: Want to help the merge? Message-ID: <200705022105.20277.jkeating@redhat.com> Here's your chance to help out! We need some changes to Makefile.common. Basically the 'make build' target needs to be smart about what client it calls, either plague or koji. Right now, only koji should be used on the devel/ branch. Changes have already been made so that koji can use the normal branches file, for devel at least. See the current 'koji' target for how it should be called. It may be easier to redirect 'make build' calls to either the 'koji' target or the 'plague' target. Makefile.common can be found in cvs.fedora.redhat.com:/cvs/pkgs in the common module. Patches gleefully reviewed and potentially accepted. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Christian.Iseli at licr.org Thu May 3 06:40:22 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 3 May 2007 08:40:22 +0200 Subject: Want to help the merge? In-Reply-To: <200705022105.20277.jkeating@redhat.com> References: <200705022105.20277.jkeating@redhat.com> Message-ID: <20070503084022.12293b3a@ludwig-alpha.unil.ch> On Wed, 2 May 2007 21:05:16 -0700, Jesse Keating wrote: > Patches gleefully reviewed and potentially accepted. Would this be enough ? C -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common.diff Type: text/x-patch Size: 1384 bytes Desc: not available URL: From jima at beer.tclug.org Thu May 3 13:45:05 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 3 May 2007 08:45:05 -0500 (CDT) Subject: Want to help the merge? In-Reply-To: <20070503084022.12293b3a@ludwig-alpha.unil.ch> References: <200705022105.20277.jkeating@redhat.com> <20070503084022.12293b3a@ludwig-alpha.unil.ch> Message-ID: On Thu, 3 May 2007, Christian Iseli wrote: > On Wed, 2 May 2007 21:05:16 -0700, Jesse Keating wrote: >> Patches gleefully reviewed and potentially accepted. > > Would this be enough ? Hey, nice. My off-the-cuff idea was along the lines of checking what $(basename `pwd`) was (devel vs. anything else). Ought to do more-or-less the same thing. I think yours might be a smidge more reliable, though. Nice to see the community kick back an answer so fast. Now, we never did anything about creating a better error warning for an expired fedora.cert, did we? I seem to recall coming up with a solution, but I wasn't sure how to best integrate it into the Makefile. Jima From jkeating at redhat.com Thu May 3 13:53:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 09:53:59 -0400 Subject: Want to help the merge? In-Reply-To: <20070503084022.12293b3a@ludwig-alpha.unil.ch> References: <200705022105.20277.jkeating@redhat.com> <20070503084022.12293b3a@ludwig-alpha.unil.ch> Message-ID: <200705030954.02828.jkeating@redhat.com> On Thursday 03 May 2007 02:40:22 Christian Iseli wrote: > Would this be enough ? I think that will do nicely. I'll run some tests. Thanks! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu May 3 14:09:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 10:09:14 -0400 Subject: Want to help the merge? In-Reply-To: <200705030954.02828.jkeating@redhat.com> References: <200705022105.20277.jkeating@redhat.com> <20070503084022.12293b3a@ludwig-alpha.unil.ch> <200705030954.02828.jkeating@redhat.com> Message-ID: <200705031009.14929.jkeating@redhat.com> On Thursday 03 May 2007 09:53:59 Jesse Keating wrote: > > Would this be enough ? > > I think that will do nicely. ?I'll run some tests. Thanks! Hrm, after hand applying the patch ( it wouldn't apply to Makefile.common directly?) I get this: $ make build make: Nothing to be done for `build'. 'make koji' still functions and does the right thing, but not make build. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Thu May 3 15:19:49 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 3 May 2007 17:19:49 +0200 Subject: Want to help the merge? In-Reply-To: <200705031009.14929.jkeating@redhat.com> References: <200705022105.20277.jkeating@redhat.com> <20070503084022.12293b3a@ludwig-alpha.unil.ch> <200705030954.02828.jkeating@redhat.com> <200705031009.14929.jkeating@redhat.com> Message-ID: <20070503171949.83adccc0.bugs.michael@gmx.net> On Thu, 3 May 2007 10:09:14 -0400, Jesse Keating wrote: > On Thursday 03 May 2007 09:53:59 Jesse Keating wrote: > > > Would this be enough ? > > > > I think that will do nicely. ?I'll run some tests. Thanks! > > Hrm, after hand applying the patch ( it wouldn't apply to Makefile.common > directly?) I get this: > > $ make build > make: Nothing to be done for `build'. > > 'make koji' still functions and does the right thing, but not make build. This one is against CVS and adds missing ';' in the $(MAKE) lines. -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common.diff2 Type: application/octet-stream Size: 1460 bytes Desc: not available URL: From jkeating at redhat.com Thu May 3 15:42:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 11:42:49 -0400 Subject: Want to help the merge? In-Reply-To: <20070503171949.83adccc0.bugs.michael@gmx.net> References: <200705022105.20277.jkeating@redhat.com> <200705031009.14929.jkeating@redhat.com> <20070503171949.83adccc0.bugs.michael@gmx.net> Message-ID: <200705031142.49372.jkeating@redhat.com> On Thursday 03 May 2007 11:19:49 Michael Schwendt wrote: > This one is against CVS and adds missing ';' in the $(MAKE) lines. Thanks! Committed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu May 3 16:41:26 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 May 2007 12:41:26 -0400 Subject: Merge status - CVS available Message-ID: <20070503164126.GC10595@nostromo.devel.redhat.com> CVS for packages should now be available at: :ext:cvs.fedora.redhat.com:/cvs/pkgs (or /cvs/extras) However, the build system is not currently active. Let us know of any problems with CVS. Bill From fedora at leemhuis.info Thu May 3 16:45:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 03 May 2007 18:45:14 +0200 Subject: Sub-Committee's Reporting to FESCo In-Reply-To: <1177854505.5779.8.camel@lincoln> References: <1177854505.5779.8.camel@lincoln> Message-ID: <463A119A.3020909@leemhuis.info> Brian Pepple schrieb: > At the last FESCo meeting, we discussed how FESCo wished the various > sub-committees (EPEL, FPC) to report their weekly summaries. The > initial proposal was to have the sub-committee send a summary to FESCo > at least 24-hours before the FESCo weekly meeting. Then during the > FESCo meeting, the chair would simply ask if there were "any objection > to this week's report of at http://", and if necessary have > a vote on any contentious issues. > > This works fine for the FPC since they meet on Tuesdays, but since EPEL > meets on Wednesday they wouldn't be able to send out a summary in time > for that week's FESCo meeting. So instead of having them wait till the > following weeks meeting, do we want to have a guideline that on > summaries that aren't sent to FESCo in time, FESCo members have 3 > business days after the summary is sent to make any objections known? My 2 cent: ---- Sub-Committee like EPEL or Fedora Packaging Committee have to create a weekly report of their important doings, meetings and the major decisions. Those reports gets send to FESCo (either to the list directly or via the FESCo chair) as well as to fedora-maintainers @ redhat com for public discussion. FESCo members should raise any concerns in public after the report got send. If two or more FESCo members say "this should be further discussed" in less than 72 hours after the report got sent the issue should be put on hold until being further discussed. ---- CU thl From jkeating at redhat.com Thu May 3 18:15:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 14:15:57 -0400 Subject: Merge Status - Building available Message-ID: <200705031416.00604.jkeating@redhat.com> It is now possible to do builds for devel/. 'make build' from a checkout will do the right thing, provided you've installed koji from extras and ran the setup utility. See http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge/FAQ Koji will take your build and run with it, you'll see some output on the CLI. Your build, if successful, will be tagged with 'dist-fc7'. This is not enough to get it into rawhide, as F7 is in continual slush freeze. If you need your build to get into rawhide and thus Fedora 7, you need to follow the policy http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy here. Rawhide (once we get that going again) will compose from the 'f7-final' tag. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cworth at redhat.com Thu May 3 18:43:30 2007 From: cworth at redhat.com (Carl Worth) Date: Thu, 03 May 2007 11:43:30 -0700 Subject: Merge Status - Building available In-Reply-To: <200705031416.00604.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> Message-ID: <87abwln3xp.wl%cworth@cworth.org> On Thu, 3 May 2007 14:15:57 -0400, Jesse Keating wrote: > Koji will take your build and run with it, you'll see some output on the CLI. > Your build, if successful, will be tagged with 'dist-fc7'. This is not > enough to get it into rawhide, as F7 is in continual slush freeze. ... > Rawhide (once we get that going again) will compose from the 'f7-final' tag. Are you saying that a build made in the interim, (tagged with dist-fc7 but not intended for F7), will also not make it into the post-F7 rawhide without another rebuild at that point? -Carl (looking forward to the day when we will start using version-control branching and merging to solve situations like this...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu May 3 18:57:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 14:57:23 -0400 Subject: Merge Status - Building available In-Reply-To: <87abwln3xp.wl%cworth@cworth.org> References: <200705031416.00604.jkeating@redhat.com> <87abwln3xp.wl%cworth@cworth.org> Message-ID: <200705031457.23630.jkeating@redhat.com> On Thursday 03 May 2007 14:43:30 Carl Worth wrote: > Are you saying that a build made in the interim, (tagged with dist-fc7 > but not intended for F7), will also not make it into the post-F7 > rawhide without another rebuild at that point? No, dist-fc8, once created, will inherit from dist-fc7 and thus pick up all those builds. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Thu May 3 18:58:31 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 3 May 2007 21:58:31 +0300 Subject: Merge Status - Building available In-Reply-To: <200705031416.00604.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> Message-ID: <200705032158.32153.ville.skytta@iki.fi> On Thursday 03 May 2007, Jesse Keating wrote: > It is now possible to do builds for devel/. What's the status of ppc64 for F7? It looks like koji builds for ppc64 by default, which means a lot of ex-Extras builds will fail because their ex-Extras dependencies are not available for ppc64. For example, my vdr-femon build failed because there's no ppc64 vdr available at the moment: http://koji.fedoraproject.org/koji/taskinfo?taskID=1445 Are there plans to eg. auto-rebuild all ex-Extras packages from the latest tag in devel for ppc64, or are packagers expected to take care of this through usual rebuilds, or will ppc64 be disabled by default before F7, or something else? Anyway, contributor view of the merge and koji look promising on first sight to me, good job. Extra points for preserving the /cvs/extras CVS repo path and fedora-packager-setup.sh config migration in koji. From caillon at redhat.com Thu May 3 19:05:31 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 03 May 2007 15:05:31 -0400 Subject: Merge status - CVS available In-Reply-To: <20070503164126.GC10595@nostromo.devel.redhat.com> References: <20070503164126.GC10595@nostromo.devel.redhat.com> Message-ID: <463A327B.8000508@redhat.com> Bill Nottingham wrote: > CVS for packages should now be available at: > > :ext:cvs.fedora.redhat.com:/cvs/pkgs (or /cvs/extras) > > However, the build system is not currently active. Let > us know of any problems with CVS. It might be nice to be able to turn off email for commits to things I'm in acls for. While I have access to many packages for committing, I don't necessarily want email for all of them. From notting at redhat.com Thu May 3 19:18:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 May 2007 15:18:01 -0400 Subject: change in e-mail notification Message-ID: <20070503191801.GB14636@nostromo.devel.redhat.com> Due to popular request, direct e-mail notifications on package changes are now (in addition to fedora-extras-commits) sent only to the package owners, not to the owners and anyone in the ACL. Bill From jkeating at redhat.com Thu May 3 19:45:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 15:45:56 -0400 Subject: PPC64 builds (was Re: Merge Status - Building available) In-Reply-To: <200705032158.32153.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <200705032158.32153.ville.skytta@iki.fi> Message-ID: <200705031545.56868.jkeating@redhat.com> On Thursday 03 May 2007 14:58:31 Ville Skytt? wrote: > On Thursday 03 May 2007, Jesse Keating wrote: > > It is now possible to do builds for devel/. > > What's the status of ppc64 for F7? > > It looks like koji builds for ppc64 by default, which means a lot of > ex-Extras builds will fail because their ex-Extras dependencies are not > available for ppc64. > > For example, my vdr-femon build failed because there's no ppc64 vdr > available at the moment: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1445 > > Are there plans to eg. auto-rebuild all ex-Extras packages from the latest > tag in devel for ppc64, or are packagers expected to take care of this > through usual rebuilds, or will ppc64 be disabled by default before F7, or > something else? > Egads. We had thought about this at one point, and it seems to have slipped our collective minds. Many things will be able to build, but some thing that require previously Extras packages in the buildroot will fail. I've setup a tracker bug to track these. If your package fails to build, please file a bug for it and block 'PPC64MissingDeps'. We will be trying to fix these asap, by bootstrapping and rebuilding ex-Extras packages to generate a ppc64 build of them. If at all possible, please do not ExcludeArch: ppc64. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cweyl at alumni.drew.edu Thu May 3 20:44:49 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 3 May 2007 13:44:49 -0700 Subject: Branching? Message-ID: <7dd7ab490705031344k1cc6f704q6a99747f74c4b88d@mail.gmail.com> I suspect this is probably fairly low on the priority list, but when can we expect CVS branching (especially for not-yet-imported packages) to begin again? -Chris -- Chris Weyl Ex astris, scientia From bpepple at fedoraproject.org Thu May 3 21:06:55 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 03 May 2007 17:06:55 -0400 Subject: Branching? In-Reply-To: <7dd7ab490705031344k1cc6f704q6a99747f74c4b88d@mail.gmail.com> References: <7dd7ab490705031344k1cc6f704q6a99747f74c4b88d@mail.gmail.com> Message-ID: <1178226415.5828.8.camel@lincoln> On Thu, 2007-05-03 at 13:44 -0700, Chris Weyl wrote: > I suspect this is probably fairly low on the priority list, but when > can we expect CVS branching (especially for not-yet-imported packages) > to begin again? Next Thursday. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Thu May 3 21:10:30 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 03 May 2007 17:10:30 -0400 Subject: FESCo Meeting Summary for 2007-05-03 Message-ID: <1178226630.5828.12.camel@lincoln> = 2007 May 03 FESCo Meeting = === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Rex Dieter (rdieter) * Jesse Keating (f13) * Christian Iseli (c4chris) * Toshio Kuratomi (abadger1999) * Jeremy Katz (jeremy) * Bill Nottingham (notting) * Warren Togami (warren) * Kevin Fenzi (nirik) * Tom Callaway (spot) === Absent === * Josh Boyer (jwb) * Dennis Gilmore (dgilmore) == Summary == === CVS Branching === * CVS will be branched next week (2007-05-10). * After F7 is released, FESCo will address when future branchings should occur. === Test release after merge? === * FESCo discussed whether to have a test release after the merge is finished. It was decided that the daily spins being currently generated is sufficient. === Bugzilla changes due to merge === * Plan is to add all Extras components to Fedora Core, and then rename that component 'Fedora'. Then all Extras bugs will be moved to 'Fedora' in the database. === Meeting Minutes IRC bot === * Since this is a fairly low priority item, we'll look into this after F7 has been released. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070503 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Thu May 3 21:15:09 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 03 May 2007 17:15:09 -0400 Subject: Branching? In-Reply-To: <1178226415.5828.8.camel@lincoln> References: <7dd7ab490705031344k1cc6f704q6a99747f74c4b88d@mail.gmail.com> <1178226415.5828.8.camel@lincoln> Message-ID: <1178226909.5828.15.camel@lincoln> On Thu, 2007-05-03 at 17:06 -0400, Brian Pepple wrote: > On Thu, 2007-05-03 at 13:44 -0700, Chris Weyl wrote: > > I suspect this is probably fairly low on the priority list, but when > > can we expect CVS branching (especially for not-yet-imported packages) > > to begin again? > > Next Thursday. > D'oh! That's when we're branching devel, which is not what you were looking for I'm guessing. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bnocera at redhat.com Thu May 3 21:34:33 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 03 May 2007 22:34:33 +0100 Subject: Merge Status - Building available In-Reply-To: <200705031416.00604.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> Message-ID: <1178228073.3158.157.camel@cookie.hadess.net> On Thu, 2007-05-03 at 14:15 -0400, Jesse Keating wrote: > It is now possible to do builds for devel/. > > 'make build' from a checkout will do the right thing, provided you've > installed koji from extras and ran the setup utility. See > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge/FAQ > > Koji will take your build and run with it, you'll see some output on the CLI. > Your build, if successful, will be tagged with 'dist-fc7'. This is not > enough to get it into rawhide, as F7 is in continual slush freeze. If you > need your build to get into rawhide and thus Fedora 7, you need to follow the > policy http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > here. > > Rawhide (once we get that going again) will compose from the 'f7-final' tag. Huh. The FAQ is lacking, or I'm an idiot (or both). > $ /usr/bin/fedora-packager-setup.sh > Creating User Koji environment > creating cert for import into browser to allow user authentication on > the website. I can't find "cert" in the dictionary. > Choose your own password, you will be propmted for this when using > the cert. There's a typo in "prompted", I don't even know what that password is supposed to do. > - import pkcs12 cert into Firefox: > > Edit -> Preferences -> Advanced > Click View Certificates > On Your Certificates tab, click Import > Select fedora-client-cert.p12 > Type the export password (if you specified one) > You should see your username appear under Fedora Project Under Fedora Project? Where? > - You should now be able to click the login link on the website > successfully Which website? > Enter Export Password: > Verifying - Enter Export Password: What's that password for again? And I still can't checkout packages in CVS. How do I get my ssh key added to cvs.fedora.redhat.com ? Cheers From cweyl at alumni.drew.edu Thu May 3 21:56:21 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 3 May 2007 14:56:21 -0700 Subject: Branching? In-Reply-To: <1178226909.5828.15.camel@lincoln> References: <7dd7ab490705031344k1cc6f704q6a99747f74c4b88d@mail.gmail.com> <1178226415.5828.8.camel@lincoln> <1178226909.5828.15.camel@lincoln> Message-ID: <7dd7ab490705031456p1c0e242fte7fe1f2789850865@mail.gmail.com> On 5/3/07, Brian Pepple wrote: > On Thu, 2007-05-03 at 17:06 -0400, Brian Pepple wrote: > > On Thu, 2007-05-03 at 13:44 -0700, Chris Weyl wrote: > > > I suspect this is probably fairly low on the priority list, but when > > > can we expect CVS branching (especially for not-yet-imported packages) > > > to begin again? > > > > Next Thursday. > > D'oh! That's when we're branching devel, which is not what you were > looking for I'm guessing. I'll admit -- it did sound a touch longer than I expected :) -Chris -- Chris Weyl Ex astris, scientia From cworth at redhat.com Thu May 3 22:01:06 2007 From: cworth at redhat.com (Carl Worth) Date: Thu, 03 May 2007 15:01:06 -0700 Subject: Merge Status - Building available In-Reply-To: <1178228073.3158.157.camel@cookie.hadess.net> References: <200705031416.00604.jkeating@redhat.com> <1178228073.3158.157.camel@cookie.hadess.net> Message-ID: <871whxmusd.wl%cworth@cworth.org> On Thu, 03 May 2007 22:34:33 +0100, Bastien Nocera wrote: > And I still can't checkout packages in CVS. How do I get my ssh key > added to cvs.fedora.redhat.com ? When I had the same question, I googled for "fedora account" and found this page: https://admin.fedoraproject.org/accounts/ From there I clicked the "edit your account" link and was able to get past the authentication dialog to a form that includes a field labelled: SSHv2 Public Key (attach your ~/.ssh/id_dsa.pub file here): After submitting that form I still wasn't able to checkout anything from cvs. I mailed admin at fedoraproject.org about it, but we haven't come to a solution yet. (The web form doesn't give me any feedback to verify my key was uploaded correctly, but an admin did email it back to me, so the upload at least seems to have worked.) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Thu May 3 22:10:41 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 3 May 2007 18:10:41 -0400 Subject: Status of the merge In-Reply-To: <200705021542.47760.jkeating@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> Message-ID: <20070503221041.GA20498@redhat.com> On Wed, May 02, 2007 at 03:42:47PM -0700, Jesse Keating wrote: > On Wednesday 02 May 2007 15:39:52 Roland McGrath wrote: > > The useless email I got made it look like extras/foo/devel/Makefile was > > getting fresh boilerplate, not copying dist/foo/devel/Makefile. ?Is this > > going to lose custom Core devel/Makefile or FC-*/Makefile contents that had > > a superset of the old /cvs/dist boilerplate Makefile functionality? > > Yes, cvs.fedora Makefile.common diverged from Red Hat's internal > Makefile.common. Much in RH's doesn't make sense in Fedora's, but some does. > If you find functionality missing, please request specific things get added > in. Comparing the diff, this is one thing that jumped out at me which would be nice to have (again). @@ -151,7 +175,13 @@ sources: $(SOURCEFILES) $(TARGETS) # Retrieve the sources we do not have in CVS $(SOURCEFILES): #FORCE @mkdir -p $(SOURCEDIR) - @echo "Downloading $@..." + @for i in `find ../ -maxdepth 2 -name "$@"`; do \ + if test "$$(md5sum $$i | awk '{print $$1}')" = "$(get_sources_md5)" ; then \ + echo "Copying from $$i" ; \ + ln $$i $@ ; \ + break ; \ + fi ; \ + done @if [ ! -e "$@" ] ; then $(CLIENT) $(REPOSITORY)/$(NAME)/$@/$(get_sources_md5)/$@ ; fi @if [ ! -e "$@" ] ; then echo "Could not download source file: $@ does not exist" ; exit 1 ; fi @if test "$$(md5sum $@ | awk '{print $$1}')" != "$(get_sources_md5)" ; then \ -- http://www.codemonkey.org.uk From jkeating at redhat.com Thu May 3 22:12:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 18:12:05 -0400 Subject: Merge Status - Building available In-Reply-To: <1178228073.3158.157.camel@cookie.hadess.net> References: <200705031416.00604.jkeating@redhat.com> <1178228073.3158.157.camel@cookie.hadess.net> Message-ID: <200705031812.05288.jkeating@redhat.com> On Thursday 03 May 2007 17:34:33 Bastien Nocera wrote: > > $ /usr/bin/fedora-packager-setup.sh > > Creating User Koji environment > > creating cert for import into browser to allow user authentication on > > the website. > > I can't find "cert" in the dictionary. SSL Certificate. Sure, it could be spelled out. > > Choose your own password, ?you will be propmted for this when using > > the cert. > > There's a typo in "prompted", I don't even know what that password is > supposed to do. It is a password to decrypt the SSL Cert for use in your browser. This cert will allow you to interact with Koji's webpage in an authenticated manner, for doing things like setting up package notifications. > > - import pkcs12 cert into Firefox: > > > > Edit -> Preferences -> Advanced > > Click View Certificates > > On Your Certificates tab, click Import > > Select fedora-client-cert.p12 > > Type the export password (if you specified one) > > You should see your username appear under Fedora Project > > Under Fedora Project? Where? Once the Certificate is imported, it will be listed as "Fedora Project". Your username will be listed underneath this. > > - You should now be able to click the login link on the website > > successfully > > Which website? http://koji.fedoraproject.org/koji > > Enter Export Password: > > Verifying - Enter Export Password: > > What's that password for again? > > And I still can't checkout packages in CVS. How do I get my ssh key > added to cvs.fedora.redhat.com ? You need to have a Fedora Account with sponsored level cvsextras membership. Once that is done, an hourly sync script will put your ssh key in all the right places so that you can access CVS. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu May 3 22:31:24 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 3 May 2007 14:31:24 -0800 Subject: change in e-mail notification In-Reply-To: <20070503191801.GB14636@nostromo.devel.redhat.com> References: <20070503191801.GB14636@nostromo.devel.redhat.com> Message-ID: <604aa7910705031531w20622d58i2b2d5bb6d44508e6@mail.gmail.com> On 5/3/07, Bill Nottingham wrote: > Due to popular request, direct e-mail notifications on package changes > are now (in addition to fedora-extras-commits) sent only to the package > owners, not to the owners and anyone in the ACL. Is that just owners as in the primary maintainer. Or owners as in everyone who thinks of themselves as co-maintainers? -jef From notting at redhat.com Thu May 3 23:32:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 3 May 2007 19:32:04 -0400 Subject: change in e-mail notification In-Reply-To: <604aa7910705031531w20622d58i2b2d5bb6d44508e6@mail.gmail.com> References: <20070503191801.GB14636@nostromo.devel.redhat.com> <604aa7910705031531w20622d58i2b2d5bb6d44508e6@mail.gmail.com> Message-ID: <20070503233204.GB22450@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > On 5/3/07, Bill Nottingham wrote: > >Due to popular request, direct e-mail notifications on package changes > >are now (in addition to fedora-extras-commits) sent only to the package > >owners, not to the owners and anyone in the ACL. > > Is that just owners as in the primary maintainer. Or owners as in > everyone who thinks of themselves as co-maintainers? Those in the owner field in owners.list and owners.epel.list. Bill From jeff at ocjtech.us Thu May 3 23:55:19 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 03 May 2007 18:55:19 -0500 Subject: Bordeaux -> Zod -> ? Zod is a , is a In-Reply-To: <1177686367.4321.11.camel@localhost.localdomain> References: <200704261322.01077.jkeating@redhat.com> <20070426174421.GB3756@nostromo.devel.redhat.com> <200704261348.10615.jkeating@redhat.com> <20070426180151.GC3756@nostromo.devel.redhat.com> <1177612328.14131.4.camel@cutter> <1177686367.4321.11.camel@localhost.localdomain> Message-ID: <1178236519.3676.16.camel@lt21223.campus.dmacc.edu> On Fri, 2007-04-27 at 11:06 -0400, Paul W. Frields wrote: > On Thu, 2007-04-26 at 14:32 -0400, seth vidal wrote: > > On Thu, 2007-04-26 at 14:01 -0400, Bill Nottingham wrote: > > > Jesse Keating (jkeating at redhat.com) said: > > > > > Hannibal > > > > > > > > Oh man, I like this one. F9 could be another famous cannibal? > > > > > > I love it when a plan comes together. > > > > that was so _wrong_. > > I'm readying my vote for "Donner" for F8, which segues nicely to a > selection of film directors (Kurosawa? Truffaut? ah, a personal sweet > spot...) for F9. F9 should definitely then be "Ed Wood". Jeff -------------- 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 davej at redhat.com Fri May 4 03:26:28 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 3 May 2007 23:26:28 -0400 Subject: Merge status - CVS available In-Reply-To: <20070503164126.GC10595@nostromo.devel.redhat.com> References: <20070503164126.GC10595@nostromo.devel.redhat.com> Message-ID: <20070504032628.GA28412@redhat.com> On Thu, May 03, 2007 at 12:41:26PM -0400, Bill Nottingham wrote: > CVS for packages should now be available at: > > :ext:cvs.fedora.redhat.com:/cvs/pkgs (or /cvs/extras) > > However, the build system is not currently active. Let > us know of any problems with CVS. odd warning (seems to work though) .. $ cvs -d:pserver:anonymous at cvs.fedora.redhat.com:/cvs/pkgs co -r kernel-2_6_21-1_3132_fc7 kernel/devel/kernel-2.6.spec cvs checkout: warning: cannot open /cvs/pkgs/CVSROOT/val-tags read/write: Permission denied U kernel/devel/kernel-2.6.spec Dave -- http://www.codemonkey.org.uk From cweyl at alumni.drew.edu Fri May 4 03:38:58 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 3 May 2007 20:38:58 -0700 Subject: koji queue vs plague queue behaviour Message-ID: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> So when one does a "make build" and koji is kicked off, it looks like we get to sit there and watch the job run, vs the "queue and return" behaviour of plague. This is especially odd as "make build" will return quickly when it happens to be talking to plague, but just hang around watching the job when it's talking to koji. Now, I actually rather like watching this, but it makes scripted operations (e.g. kick off several builds at once) rather inefficient. Is there a way to cause koji to return once the job is queued? And further, is there a way an individual packager can cause koji to return after queuing when using the "make build" target? Or can we just change things globally to revert to the expected behaviour? -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Fri May 4 03:42:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 May 2007 20:42:40 -0700 Subject: koji queue vs plague queue behaviour In-Reply-To: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> Message-ID: <200705032042.41188.jkeating@redhat.com> On Thursday 03 May 2007 20:38:58 Chris Weyl wrote: > So when one does a "make build" and koji is kicked off, it looks like > we get to sit there and watch the job run, vs the "queue and return" > behaviour of plague. ?This is especially odd as "make build" will > return quickly when it happens to be talking to plague, but just hang > around watching the job when it's talking to koji. ?Now, I actually > rather like watching this, but it makes scripted operations (e.g. kick > off several builds at once) rather inefficient. > > Is there a way to cause koji to return once the job is queued? KOJI_FLAGS="--nowait" or I do believe you can set something in .kojirc like this. > And further, is there a way an individual packager can cause koji to > return after queuing when using the "make build" target? ?Or can we > just change things globally to revert to the expected behaviour? Do your build with KOJI_FLAGS="--nowait" and it will return as soon as queued. I thought about making this the default, however that would mean nobody could watch it. So the default is watch it, the option is available to make it return. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cweyl at alumni.drew.edu Fri May 4 03:52:42 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 3 May 2007 20:52:42 -0700 Subject: koji queue vs plague queue behaviour In-Reply-To: <200705032042.41188.jkeating@redhat.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> Message-ID: <7dd7ab490705032052k43163dbr35aba01a1b820205@mail.gmail.com> On 5/3/07, Jesse Keating wrote: > Do your build with KOJI_FLAGS="--nowait" and it will return as soon as queued. > I thought about making this the default, however that would mean nobody could > watch it. So the default is watch it, the option is available to make it > return. Works by me. Thanks :) -Chris -- Chris Weyl Ex astris, scientia From jspaleta at gmail.com Fri May 4 04:59:26 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 3 May 2007 20:59:26 -0800 Subject: koji queue vs plague queue behaviour In-Reply-To: <200705032042.41188.jkeating@redhat.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> Message-ID: <604aa7910705032159t24686f38w42b1ec2a5a5cc9ad@mail.gmail.com> On 5/3/07, Jesse Keating wrote: > Do your build with KOJI_FLAGS="--nowait" and it will return as soon as queued. > I thought about making this the default, however that would mean nobody could > watch it. So the default is watch it, the option is available to make it > return. Oh, sounds to me like there's room to slap on a layer of tastefully done eyecandy in the form of a status tray icon in lieu of watching it in the terminal. -jef"And by tasteful, I'm thinking dancing circus bears"spaleta From dwmw2 at infradead.org Fri May 4 05:56:20 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 04 May 2007 06:56:20 +0100 Subject: PPC64 builds (was Re: Merge Status - Building available) In-Reply-To: <200705031545.56868.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705032158.32153.ville.skytta@iki.fi> <200705031545.56868.jkeating@redhat.com> Message-ID: <1178258180.11120.252.camel@pmac.infradead.org> On Thu, 2007-05-03 at 15:45 -0400, Jesse Keating wrote: > Egads. We had thought about this at one point, and it seems to have slipped > our collective minds. Many things will be able to build, but some thing that > require previously Extras packages in the buildroot will fail. I've setup a > tracker bug to track these. If your package fails to build, please file a > bug for it and block 'PPC64MissingDeps'. We will be trying to fix these > asap, by bootstrapping and rebuilding ex-Extras packages to generate a ppc64 > build of them. If at all possible, please do not ExcludeArch: ppc64. And if you do ExcludeArch: ppc64 remember that _ALL_ uses of ExcludeArch: must have a corresponding bug filed, even if it's just an explanation. And that bug must be on the corresponding ExcludeArch tracker bug. I've created the tracker bug (#238953) for ppc64 -- aliased 'FE-ExcludeArch-ppc64' for consistency with the others, which will all probably drop the leading 'FE-' from the name at some point. We _really_ ought to start enforcing this "ExcludeArch must have bug" rule in the build system. -- dwmw2 From caolanm at redhat.com Fri May 4 07:11:30 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 04 May 2007 08:11:30 +0100 Subject: Merge Status - Building available In-Reply-To: <871whxmusd.wl%cworth@cworth.org> References: <200705031416.00604.jkeating@redhat.com> <1178228073.3158.157.camel@cookie.hadess.net> <871whxmusd.wl%cworth@cworth.org> Message-ID: <1178262690.2579.1.camel@localhost.localdomain> On Thu, 2007-05-03 at 15:01 -0700, Carl Worth wrote: > From there I clicked the "edit your account" link and was able to get > past the authentication dialog to a form that includes a field > labelled: > > SSHv2 Public Key (attach your ~/.ssh/id_dsa.pub file here): > > After submitting that form I still wasn't able to checkout anything > from cvs. Give it a go at checking out at time X+1:05 when uploading at time X:Y. The key only comes active after some cronjob picks it up on the next change of the hour apparently. C. From jorton at redhat.com Fri May 4 10:02:47 2007 From: jorton at redhat.com (Joe Orton) Date: Fri, 4 May 2007 11:02:47 +0100 Subject: Merge Status - Building available In-Reply-To: <1178228073.3158.157.camel@cookie.hadess.net> References: <200705031416.00604.jkeating@redhat.com> <1178228073.3158.157.camel@cookie.hadess.net> Message-ID: <20070504100247.GA3387@redhat.com> On Thu, May 03, 2007 at 10:34:33PM +0100, Bastien Nocera wrote: > > Enter Export Password: > > Verifying - Enter Export Password: > > What's that password for again? You don't need to enter a password here at all, all the script is doing is converting the client cert from PEM format (OpenSSL default) to PKCS#12 format, suitable for importing into Firefox. Just hit return at both the prompts, and hit return again when Firefox prompts when importing the cert. joe From jorton at redhat.com Fri May 4 10:05:17 2007 From: jorton at redhat.com (Joe Orton) Date: Fri, 4 May 2007 11:05:17 +0100 Subject: Status of the merge In-Reply-To: <200705021542.47760.jkeating@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> Message-ID: <20070504100517.GB3387@redhat.com> On Wed, May 02, 2007 at 03:42:47PM -0700, Jesse Keating wrote: > Yes, cvs.fedora Makefile.common diverged from Red Hat's internal > Makefile.common. Much in RH's doesn't make sense in Fedora's, but some does. > If you find functionality missing, please request specific things get added > in. Can you add these changes? Allows a standard "make patch CVS=xxxx-yyyy" and "make unused-patches | xargs cvs rm -f". --- Makefile.common.~1.52.~ 2007-05-03 22:36:56.000000000 +0100 +++ Makefile.common 2007-05-04 10:56:31.000000000 +0100 @@ -400,7 +400,13 @@ FILTERDIFF := cat endif +ifdef CVE +PATCHFILE := $(NAME)-$(VERSION)-CVE-$(CVE).patch +SUFFIX := cve$(shell echo $(CVE) | sed s/.*-//) +else PATCHFILE := $(NAME)-$(VERSION)-$(SUFFIX).patch +endif + patch: @if test -z "$(SUFFIX)"; then echo "Must specify SUFFIX=whatever" ; exit 1; fi (cd $(RPM_BUILD_DIR)/.. && gendiff $(NAME)-$(VERSION) .$(SUFFIX) | $(FILTERDIFF)) > $(PATCHFILE) || true @@ -445,11 +451,15 @@ @echo " clean Remove srcs ($(SOURCEFILES)), export dir (cvs-$(TAG)) and srpm ($(NAME)-$(VERSION)-$(RELEASE).src.rpm)" @echo " patch SUFFIX= Create and add a gendiff patch file" @echo " rediff SUFFIX= Recreates a gendiff patch file, retaining comments" + @echo " unused-patches Print list of patches not referenced by name in specfile" @echo " gimmespec Print the name of the specfile" gimmespec: @echo "$(SPECFILE)" +unused-patches: + @for f in *.patch; do if [ -e $$f ]; then grep -q $$f $(SPECFILE) || echo $$f; fi; done + ##################### EXPERIMENTAL ########################## # this stuff is very experimental in nature and should not be # relied upon until these targets are moved above this line From tjanouse at redhat.com Fri May 4 10:54:26 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 4 May 2007 12:54:26 +0200 Subject: Status of the merge In-Reply-To: <200705021542.47760.jkeating@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> Message-ID: <20070504105426.GA11699@redhat.com> Hi, On Wed, May 02, 2007 at 03:42:47PM -0700, Jesse Keating wrote: > Yes, cvs.fedora Makefile.common diverged from Red Hat's internal > Makefile.common. Much in RH's doesn't make sense in Fedora's, but some does. > If you find functionality missing, please request specific things get added > in. For all who use private branches, the following patch may be helpful. I added it to RH's Makefile.common recently, being inspired by `make zstreams'. --- diff -u -r1.51 Makefile.common --- Makefile.common 3 May 2007 19:11:07 -0000 1.51 +++ Makefile.common 3 May 2007 20:33:52 -0000 @@ -445,6 +445,28 @@ gimmespec: @echo "$(SPECFILE)" +privates: $(SPECFILE) + @for P_BRANCH in $$(cvs -f log -h $(SPECFILE) | awk '/private-.*-branch/ { print substr($$1, 0, length($$1) - 1) }'); do \ + P_DIR=$${P_BRANCH%-branch}; \ + P_DIR=$${P_DIR#private-}; \ + P_DIR=$(BRANCH)-$${P_DIR}; \ + pushd .. > /dev/null; \ + if [ -d $$P_DIR ]; then \ + cd $$P_DIR; \ + if [ ! -f CVS/Tag ] || [ $$(cat CVS/Tag) != "T$$P_BRANCH" ]; then \ + echo "$$P_DIR exists but is not on branch $$P_BRANCH"; \ + exit 1; \ + else \ + echo "Updating $$P_DIR..."; \ + cvs up; \ + fi; \ + else \ + echo "Checking out $$P_BRANCH into $$P_DIR..."; \ + cvs co -r $$P_BRANCH -d $$P_DIR rpms/$(NAME)/$(BRANCH); \ + fi; \ + popd > /dev/null; \ + done + ##################### EXPERIMENTAL ########################## # this stuff is very experimental in nature and should not be # relied upon until these targets are moved above this line -- TJ. (Brno, CZ), BaseOS, Red Hat From blizzard at redhat.com Fri May 4 12:46:41 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Fri, 04 May 2007 08:46:41 -0400 Subject: Status of the merge In-Reply-To: <20070504105426.GA11699@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> <20070504105426.GA11699@redhat.com> Message-ID: <1178282801.14525.2.camel@localhost.localdomain> Man, I love all this Makefile.common hacking. Pretty cool. :) --Chris From mtasaka at ioa.s.u-tokyo.ac.jp Fri May 4 13:33:53 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 04 May 2007 22:33:53 +0900 Subject: Merge Status - Building available In-Reply-To: <200705031416.00604.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> Message-ID: <463B3641.5090406@ioa.s.u-tokyo.ac.jp> A couple of questions: Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: > Koji will take your build and run with it, you'll see some output on the CLI. > Your build, if successful, will be tagged with 'dist-fc7'. This is not > enough to get it into rawhide, as F7 is in continual slush freeze. If you > need your build to get into rawhide and thus Fedora 7, you need to follow the > policy http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > here. Well, A. Does this mean that many packages which were approved and were rebuilt after koji began to work (then marked as 'dist-fc7') will not be pushed into Fedora 7, while they will be pushed into Fedora _Extras_ 6/5 as before (usually within two days)? (i.e. will this cause the situation that newer packages will appear on FE-5/6, but not on Fedora 7)? B. There are still many packages which are still waiting for review and some of them require rpms marked as dist-fc7 as BuildRequires. If the situation A is true, how can I check if a package can be rebuilt with mock correctly which I want to review and which requires dist-fc7 rpms (which are not pushed into public yet)? Before koji began to work, mock used to pull such BuildRequires rpms from http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ , which included repodata (marked as "local" repository) and mock could use such rpms "which were just rebuilt but not formally pushed into public" as BuildRequires. For koji, are there any repodata of dist-fc7 which contains "not formally pushed rpms" which can be used for mock build needed for package review as before? (i.e. I want to install "just rebuilt rpms" from repository like "local" repository as quickly as possible because I _frequently_ meet the situation in which such "new" rpms are needed for review"). Regards, Mamoru From jwboyer at jdub.homelinux.org Fri May 4 13:34:54 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 May 2007 08:34:54 -0500 Subject: Merge Status - Building available In-Reply-To: <463B3641.5090406@ioa.s.u-tokyo.ac.jp> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> Message-ID: <1178285694.3026.166.camel@zod.rchland.ibm.com> On Fri, 2007-05-04 at 22:33 +0900, Mamoru Tasaka wrote: > A couple of questions: > > Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: > > > Koji will take your build and run with it, you'll see some output on the CLI. > > Your build, if successful, will be tagged with 'dist-fc7'. This is not > > enough to get it into rawhide, as F7 is in continual slush freeze. If you > > need your build to get into rawhide and thus Fedora 7, you need to follow the > > policy http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > here. > > Well, > A. Does this mean that many packages which were approved and were > rebuilt after koji began to work (then marked as 'dist-fc7') > will not be pushed into Fedora 7, > while they will be pushed into Fedora _Extras_ 6/5 as before (usually > within two days)? (i.e. will this cause the situation that > newer packages will appear on FE-5/6, but not on Fedora 7)? Unless you submit a request to rel-eng, yes. You need to have those packages tagged as f7-final if you want them in the release. > > B. There are still many packages which are still waiting for review and > some of them require rpms marked as dist-fc7 as BuildRequires. > If the situation A is true, how can I check if a package can be > rebuilt with mock correctly which I want to review and which > requires dist-fc7 rpms (which are not pushed into public yet)? > > Before koji began to work, mock used to pull such BuildRequires rpms > from > http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ , > which included repodata (marked as "local" repository) and mock could use > such rpms "which were just rebuilt but not formally pushed into public" as > BuildRequires. > > For koji, are there any repodata of dist-fc7 which contains "not formally > pushed rpms" which can be used for mock build needed for package review > as before? (i.e. I want to install "just rebuilt rpms" from repository > like "local" repository as quickly as possible because I _frequently_ > meet the situation in which such "new" rpms are needed for review"). This is a good question that I don't know the answer to. Jesse, Dennis? josh From tibbs at math.uh.edu Fri May 4 14:28:24 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 May 2007 09:28:24 -0500 Subject: Status of the merge In-Reply-To: <1178282801.14525.2.camel@localhost.localdomain> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> <20070504105426.GA11699@redhat.com> <1178282801.14525.2.camel@localhost.localdomain> Message-ID: >>>>> "CB" == Christopher Blizzard writes: CB> Man, I love all this Makefile.common hacking. I as well, as long as all of the new targets are documented somewhere. - J< From giallu at gmail.com Fri May 4 14:59:54 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 4 May 2007 16:59:54 +0200 Subject: Merge Status - Building available In-Reply-To: <1178285694.3026.166.camel@zod.rchland.ibm.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> Message-ID: On 5/4/07, Josh Boyer wrote: > On Fri, 2007-05-04 at 22:33 +0900, Mamoru Tasaka wrote: > > A couple of questions: > > > > Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: > > > > > Koji will take your build and run with it, you'll see some output on the CLI. > > > Your build, if successful, will be tagged with 'dist-fc7'. This is not > > > enough to get it into rawhide, as F7 is in continual slush freeze. If you > > > need your build to get into rawhide and thus Fedora 7, you need to follow the > > > policy http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > here. > > > > Well, > > A. Does this mean that many packages which were approved and were > > rebuilt after koji began to work (then marked as 'dist-fc7') > > will not be pushed into Fedora 7, > > while they will be pushed into Fedora _Extras_ 6/5 as before (usually > > within two days)? (i.e. will this cause the situation that > > newer packages will appear on FE-5/6, but not on Fedora 7)? > > Unless you submit a request to rel-eng, yes. You need to have those > packages tagged as f7-final if you want them in the release. I'm not sure if this was asked in the past but... Is there an easy way to tell if one your packages are included in one or more of the collections? From cweyl at alumni.drew.edu Fri May 4 15:05:23 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 4 May 2007 08:05:23 -0700 Subject: koji queue vs plague queue behaviour In-Reply-To: <7dd7ab490705032052k43163dbr35aba01a1b820205@mail.gmail.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <7dd7ab490705032052k43163dbr35aba01a1b820205@mail.gmail.com> Message-ID: <7dd7ab490705040805l7425bcrad29b5d412bf6bb7@mail.gmail.com> On 5/3/07, Chris Weyl wrote: > On 5/3/07, Jesse Keating wrote: > > Do your build with KOJI_FLAGS="--nowait" and it will return as soon as queued. > > I thought about making this the default, however that would mean nobody could > > watch it. So the default is watch it, the option is available to make it > > return. > > Works by me. Thanks :) I may have spoken a bit fast: usage: koji build [options] target URL (Specify the --help global option for a list of other help options) koji: error: no such option: --no-wait I tried looking this up in the koji man page, but... there isn't one. :( -Chris -- Chris Weyl Ex astris, scientia From jwboyer at jdub.homelinux.org Fri May 4 15:00:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 May 2007 10:00:19 -0500 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> Message-ID: <1178290819.3026.172.camel@zod.rchland.ibm.com> On Fri, 2007-05-04 at 16:59 +0200, Gianluca Sforna wrote: > On 5/4/07, Josh Boyer wrote: > > On Fri, 2007-05-04 at 22:33 +0900, Mamoru Tasaka wrote: > > > A couple of questions: > > > > > > Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: > > > > > > > Koji will take your build and run with it, you'll see some output on the CLI. > > > > Your build, if successful, will be tagged with 'dist-fc7'. This is not > > > > enough to get it into rawhide, as F7 is in continual slush freeze. If you > > > > need your build to get into rawhide and thus Fedora 7, you need to follow the > > > > policy http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > > here. > > > > > > Well, > > > A. Does this mean that many packages which were approved and were > > > rebuilt after koji began to work (then marked as 'dist-fc7') > > > will not be pushed into Fedora 7, > > > while they will be pushed into Fedora _Extras_ 6/5 as before (usually > > > within two days)? (i.e. will this cause the situation that > > > newer packages will appear on FE-5/6, but not on Fedora 7)? > > > > Unless you submit a request to rel-eng, yes. You need to have those > > packages tagged as f7-final if you want them in the release. > > I'm not sure if this was asked in the past but... Is there an easy way > to tell if one your packages are included in one or more of the > collections? By collections do you mean "spins"? Or tags? The list of package builds included in the f7-final tag can be viewed via: http://koji.fedoraproject.org/koji/packages?tagID=10 josh From jwboyer at jdub.homelinux.org Fri May 4 15:01:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 04 May 2007 10:01:55 -0500 Subject: koji queue vs plague queue behaviour In-Reply-To: <7dd7ab490705040805l7425bcrad29b5d412bf6bb7@mail.gmail.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <7dd7ab490705032052k43163dbr35aba01a1b820205@mail.gmail.com> <7dd7ab490705040805l7425bcrad29b5d412bf6bb7@mail.gmail.com> Message-ID: <1178290915.3026.174.camel@zod.rchland.ibm.com> On Fri, 2007-05-04 at 08:05 -0700, Chris Weyl wrote: > On 5/3/07, Chris Weyl wrote: > > On 5/3/07, Jesse Keating wrote: > > > Do your build with KOJI_FLAGS="--nowait" and it will return as soon as queued. > > > I thought about making this the default, however that would mean nobody could > > > watch it. So the default is watch it, the option is available to make it > > > return. > > > > Works by me. Thanks :) > > I may have spoken a bit fast: > > usage: koji build [options] target URL > (Specify the --help global option for a list of other help options) > > koji: error: no such option: --no-wait --no-wait is not the same as --nowait josh From jakub at redhat.com Fri May 4 15:09:46 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 4 May 2007 11:09:46 -0400 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> Message-ID: <20070504150946.GZ355@devserv.devel.redhat.com> On Fri, May 04, 2007 at 04:59:54PM +0200, Gianluca Sforna wrote: > >Unless you submit a request to rel-eng, yes. You need to have those > >packages tagged as f7-final if you want them in the release. > > I'm not sure if this was asked in the past but... Is there an easy way > to tell if one your packages are included in one or more of the > collections? Yeah, koji latest-pkg, e.g. koji latest-pkg f7-final gcc glibc binutils prelink Jakub From cweyl at alumni.drew.edu Fri May 4 15:11:17 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 4 May 2007 08:11:17 -0700 Subject: koji queue vs plague queue behaviour In-Reply-To: <1178290915.3026.174.camel@zod.rchland.ibm.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <7dd7ab490705032052k43163dbr35aba01a1b820205@mail.gmail.com> <7dd7ab490705040805l7425bcrad29b5d412bf6bb7@mail.gmail.com> <1178290915.3026.174.camel@zod.rchland.ibm.com> Message-ID: <7dd7ab490705040811x75d71184u6a0086376a076e2b@mail.gmail.com> On 5/4/07, Josh Boyer wrote: > --no-wait is not the same as --nowait Yet the result is: usage: koji [global-options] command [command-options-and-arguments] koji: error: no such option: --nowait FWIW, koji --help shows nothing along these lines... -Chris -- Chris Weyl Ex astris, scientia From bugs.michael at gmx.net Fri May 4 15:24:42 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 May 2007 17:24:42 +0200 Subject: koji queue vs plague queue behaviour In-Reply-To: <7dd7ab490705040811x75d71184u6a0086376a076e2b@mail.gmail.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <7dd7ab490705032052k43163dbr35aba01a1b820205@mail.gmail.com> <7dd7ab490705040805l7425bcrad29b5d412bf6bb7@mail.gmail.com> <1178290915.3026.174.camel@zod.rchland.ibm.com> <7dd7ab490705040811x75d71184u6a0086376a076e2b@mail.gmail.com> Message-ID: <20070504172442.3319eb21.bugs.michael@gmx.net> On Fri, 4 May 2007 08:11:17 -0700, Chris Weyl wrote: > On 5/4/07, Josh Boyer wrote: > > --no-wait is not the same as --nowait > > Yet the result is: > > usage: koji [global-options] command [command-options-and-arguments] > > koji: error: no such option: --nowait > > FWIW, koji --help shows nothing along these lines... > Run: koji build --help From cweyl at alumni.drew.edu Fri May 4 15:30:45 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 4 May 2007 08:30:45 -0700 Subject: koji queue vs plague queue behaviour In-Reply-To: <20070504172442.3319eb21.bugs.michael@gmx.net> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <7dd7ab490705032052k43163dbr35aba01a1b820205@mail.gmail.com> <7dd7ab490705040805l7425bcrad29b5d412bf6bb7@mail.gmail.com> <1178290915.3026.174.camel@zod.rchland.ibm.com> <7dd7ab490705040811x75d71184u6a0086376a076e2b@mail.gmail.com> <20070504172442.3319eb21.bugs.michael@gmx.net> Message-ID: <7dd7ab490705040830s1952a649hefccd5c3b583a34b@mail.gmail.com> On 5/4/07, Michael Schwendt wrote: > On Fri, 4 May 2007 08:11:17 -0700, Chris Weyl wrote: > > > On 5/4/07, Josh Boyer wrote: > > > --no-wait is not the same as --nowait > > > > Yet the result is: > > > > usage: koji [global-options] command [command-options-and-arguments] > > > > koji: error: no such option: --nowait > > > > FWIW, koji --help shows nothing along these lines... > > > > Run: koji build --help Just my $0.02, this is where a man page would help... I wasn't expecting that :\ -Chris -- Chris Weyl Ex astris, scientia From katzj at redhat.com Fri May 4 15:36:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 04 May 2007 11:36:00 -0400 Subject: Status of the merge In-Reply-To: <20070503221041.GA20498@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> <20070503221041.GA20498@redhat.com> Message-ID: <1178292960.2785.0.camel@aglarond.local> On Thu, 2007-05-03 at 18:10 -0400, Dave Jones wrote: > On Wed, May 02, 2007 at 03:42:47PM -0700, Jesse Keating wrote: > > On Wednesday 02 May 2007 15:39:52 Roland McGrath wrote: > > > The useless email I got made it look like extras/foo/devel/Makefile was > > > getting fresh boilerplate, not copying dist/foo/devel/Makefile. Is this > > > going to lose custom Core devel/Makefile or FC-*/Makefile contents that had > > > a superset of the old /cvs/dist boilerplate Makefile functionality? > > > > Yes, cvs.fedora Makefile.common diverged from Red Hat's internal > > Makefile.common. Much in RH's doesn't make sense in Fedora's, but some does. > > If you find functionality missing, please request specific things get added > > in. > > Comparing the diff, this is one thing that jumped out at me which would > be nice to have (again). Added Jeremy From jkeating at redhat.com Fri May 4 15:33:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 08:33:53 -0700 Subject: Merge Status - Building available In-Reply-To: <463B3641.5090406@ioa.s.u-tokyo.ac.jp> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> Message-ID: <200705040833.57596.jkeating@redhat.com> On Friday 04 May 2007 06:33:53 Mamoru Tasaka wrote: > B. There are still many packages which are still waiting for review and > ? ?some of them require rpms marked as dist-fc7 as BuildRequires. > ? ?If the situation A is true, how can I check if a package can be > ? ?rebuilt with mock correctly which I want to review and which > ? ?requires dist-fc7 rpms (which are not pushed into public yet)? > > ? ?Before koji began to work, mock used to pull such BuildRequires rpms > ? ?from > ? > ?http://buildsys.fedoraproject.org/plague-results/fedora-development-extras >/ , which included repodata (marked as "local" repository) and mock could > use such rpms "which were just rebuilt but not formally pushed into public" > as BuildRequires. > > ? ?For koji, are there any repodata of dist-fc7 which contains "not > formally pushed rpms" which can be used for mock build needed for package > review as before? (i.e. I want to install "just rebuilt rpms" from > repository like "local" repository as quickly as possible because I > _frequently_ meet the situation in which such "new" rpms are needed for > review"). We are working on getting a public repo up each hour that contains the contents of the buildroots. It won't be multilib, but that's OK. This should allow you to build with what's hot as of an hour ago. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Fri May 4 15:36:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 04 May 2007 11:36:13 -0400 Subject: Status of the merge In-Reply-To: <20070504100517.GB3387@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> <20070504100517.GB3387@redhat.com> Message-ID: <1178292973.2785.2.camel@aglarond.local> On Fri, 2007-05-04 at 11:05 +0100, Joe Orton wrote: > On Wed, May 02, 2007 at 03:42:47PM -0700, Jesse Keating wrote: > > Yes, cvs.fedora Makefile.common diverged from Red Hat's internal > > Makefile.common. Much in RH's doesn't make sense in Fedora's, but some does. > > If you find functionality missing, please request specific things get added > > in. > > Can you add these changes? Allows a standard "make patch CVS=xxxx-yyyy" > and "make unused-patches | xargs cvs rm -f". Committed; thanks Joe Jeremy From katzj at redhat.com Fri May 4 15:37:41 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 04 May 2007 11:37:41 -0400 Subject: Status of the merge In-Reply-To: <20070504105426.GA11699@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> <20070504105426.GA11699@redhat.com> Message-ID: <1178293061.2785.4.camel@aglarond.local> On Fri, 2007-05-04 at 12:54 +0200, Tomas Janousek wrote: > On Wed, May 02, 2007 at 03:42:47PM -0700, Jesse Keating wrote: > > Yes, cvs.fedora Makefile.common diverged from Red Hat's internal > > Makefile.common. Much in RH's doesn't make sense in Fedora's, but some does. > > If you find functionality missing, please request specific things get added > > in. > > For all who use private branches, the following patch may be helpful. I added > it to RH's Makefile.common recently, being inspired by `make zstreams'. This seems okay, but can you also add appropriate documentation to the help target? Jeremy From jkeating at redhat.com Fri May 4 15:35:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 08:35:47 -0700 Subject: koji queue vs plague queue behaviour In-Reply-To: <604aa7910705032159t24686f38w42b1ec2a5a5cc9ad@mail.gmail.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <604aa7910705032159t24686f38w42b1ec2a5a5cc9ad@mail.gmail.com> Message-ID: <200705040835.48057.jkeating@redhat.com> On Thursday 03 May 2007 21:59:26 Jeff Spaleta wrote: > Oh, sounds to me like there's room to slap on a layer of tastefully > done eyecandy in the form of a status tray icon in lieu of watching it > in the terminal. XMLRPC is your friend. There is room for all _kinds_ of cool stuff built up around koji and it's friendly API. In fact, 'koji list-api' to get a list of all the exposed API calls. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laurent.rineau__fedora_extras at normalesup.org Fri May 4 15:44:34 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Fri, 4 May 2007 17:44:34 +0200 Subject: Mass rebuild for f7-merge? In-Reply-To: <200704110905.00183.jkeating@redhat.com> References: <4618E08B.9020300@fedoraproject.org> <20070411123115.GC18875@neu.nirvana> <200704110905.00183.jkeating@redhat.com> Message-ID: <200705041744.34932@rineau.tsetse> On Wednesday 11 April 2007 15:04:59 Jesse Keating wrote: > On Wednesday 11 April 2007 08:31:15 Axel Thimm wrote: > > The fc6 tag is really cosmetics in comparison to what we may run into > > w/o a proper rebuild. In fact we should really keep them (the tags), > > so when a package explodes the user/bug reporter/bug assignee will be > > able to identify the distribution the package was built on and perhaps > > derive that that's the real issue. > > With Koji, it is pretty easy to find out EXACTLY what packages were in the > buildroot to build any given package. The dist tag is not necessary for > guessing. Jesse, I?was browsing Koji's pages when I discovered that my packages were all rebuild by you the day before yesterday (2007/05/02). Actually, I discovered that the tag "f7-merge" is composed of 2998 rebuilds, made by you on Wednesday: https://koji.fedoraproject.org/koji/taginfo?tagID=11 I?am pretty sure that I have not understood something. Maybe these rebuild jobs are fake rebuilds, like a kind of copy (I?do not know if the build system can even rebuild almost 3000 packages in one day). Can you give a word about that? :-) -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From bugs.michael at gmx.net Fri May 4 15:51:41 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 4 May 2007 17:51:41 +0200 Subject: Mass rebuild for f7-merge? In-Reply-To: <200705041744.34932@rineau.tsetse> References: <4618E08B.9020300@fedoraproject.org> <20070411123115.GC18875@neu.nirvana> <200704110905.00183.jkeating@redhat.com> <200705041744.34932@rineau.tsetse> Message-ID: <20070504175141.80d5684d.bugs.michael@gmx.net> On Fri, 4 May 2007 17:44:34 +0200, Laurent Rineau wrote: > On Wednesday 11 April 2007 15:04:59 Jesse Keating wrote: > > On Wednesday 11 April 2007 08:31:15 Axel Thimm wrote: > > > The fc6 tag is really cosmetics in comparison to what we may run into > > > w/o a proper rebuild. In fact we should really keep them (the tags), > > > so when a package explodes the user/bug reporter/bug assignee will be > > > able to identify the distribution the package was built on and perhaps > > > derive that that's the real issue. > > > > With Koji, it is pretty easy to find out EXACTLY what packages were in the > > buildroot to build any given package. The dist tag is not necessary for > > guessing. > > Jesse, > > I?was browsing Koji's pages when I discovered that my packages were all > rebuild by you the day before yesterday (2007/05/02). Actually, I discovered > that the tag "f7-merge" is composed of 2998 rebuilds, made by you on > Wednesday: > > https://koji.fedoraproject.org/koji/taginfo?tagID=11 > > I?am pretty sure that I have not understood something. Maybe these rebuild > jobs are fake rebuilds, like a kind of copy (I?do not know if the build > system can even rebuild almost 3000 packages in one day). > > Can you give a word about that? :-) Your theory is correct. koji needs the "build" information for all its packages to fill database tables. From nomis80 at nomis80.org Fri May 4 15:55:21 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Fri, 4 May 2007 11:55:21 -0400 Subject: Suggestion: a list for important announcements Message-ID: <200705041155.22189.nomis80@nomis80.org> Hello, Although I'm a fedora maintainer, I don't wish to participate in the Fedora development that takes place on this mailing list. But I'm forced to quickly read most threads since it might contain stuff of importance to my maintainer job. I'm sure many people are also in this unfortunate situation. Here's a suggestion: create a list, say fedora-maintainers-announce at redhat.com, where only core people would have the right to post. These posts would be important announcements like "ok people, feature freeze for the next 3 weeks" or "please rebuild if XYZ affects you". Posts to this list would always be cross-posted to fedora-maintainers, where ensuing discussion could take place. This is inspired from a similar scheme used for KDE development. Thank you From jkeating at redhat.com Fri May 4 15:50:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 08:50:42 -0700 Subject: Mass rebuild for f7-merge? In-Reply-To: <200705041744.34932@rineau.tsetse> References: <4618E08B.9020300@fedoraproject.org> <200704110905.00183.jkeating@redhat.com> <200705041744.34932@rineau.tsetse> Message-ID: <200705040850.43230.jkeating@redhat.com> On Friday 04 May 2007 08:44:34 Laurent Rineau wrote: > Jesse, > > I?was browsing Koji's pages when I discovered that my packages were all > rebuild by you the day before yesterday (2007/05/02). Actually, I > discovered that the tag "f7-merge" is composed of 2998 rebuilds, made by > you on Wednesday: > > https://koji.fedoraproject.org/koji/taginfo?tagID=11 > > I?am pretty sure that I have not understood something. Maybe these rebuild > jobs are fake rebuilds, like a kind of copy (I?do not know if the build > system can even rebuild almost 3000 packages in one day). > > Can you give a word about that? :-) Yes, they are considered "builds" to koji as it has never seen those packages before. However they are just imports of the packages as they were built for Extras from plague. They were not actually _re_built. Since I did all the importing, it assigned me as the build owner. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 4 16:01:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 09:01:43 -0700 Subject: Suggestion: a list for important announcements In-Reply-To: <200705041155.22189.nomis80@nomis80.org> References: <200705041155.22189.nomis80@nomis80.org> Message-ID: <200705040901.44127.jkeating@redhat.com> On Friday 04 May 2007 08:55:21 Simon Perreault wrote: > Here's a suggestion: create a list, say > fedora-maintainers-announce at redhat.com, where only core people would have > the right to post. These posts would be important announcements like "ok > people, feature freeze for the next 3 weeks" or "please rebuild if XYZ > affects you". Posts to this list would always be cross-posted to > fedora-maintainers, where ensuing discussion could take place. > > This is inspired from a similar scheme used for KDE development. We have that, sortof. We just haven't kicked it into gear yet. Unfortunately with such a list you miss out on a lot of the dialog and discussion that happens around such announcements, like all the general discussion and usage suggestions for koji. You'd get the announcement that we're using koji... and not much else. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Fri May 4 16:09:34 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 05 May 2007 01:09:34 +0900 Subject: Merge Status - Building available In-Reply-To: <200705040833.57596.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <200705040833.57596.jkeating@redhat.com> Message-ID: <463B5ABE.8040006@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote, at 05/05/2007 12:33 AM +9:00: > On Friday 04 May 2007 06:33:53 Mamoru Tasaka wrote: >> B. There are still many packages which are still waiting for review and >> some of them require rpms marked as dist-fc7 as BuildRequires. >> If the situation A is true, how can I check if a package can be >> rebuilt with mock correctly which I want to review and which >> requires dist-fc7 rpms (which are not pushed into public yet)? >> >> Before koji began to work, mock used to pull such BuildRequires rpms >> from >> >> http://buildsys.fedoraproject.org/plague-results/fedora-development-extras >> / , which included repodata (marked as "local" repository) and mock could >> use such rpms "which were just rebuilt but not formally pushed into public" >> as BuildRequires. >> >> For koji, are there any repodata of dist-fc7 which contains "not >> formally pushed rpms" which can be used for mock build needed for package >> review as before? (i.e. I want to install "just rebuilt rpms" from >> repository like "local" repository as quickly as possible because I >> _frequently_ meet the situation in which such "new" rpms are needed for >> review"). > > We are working on getting a public repo up each hour that contains the > contents of the buildroots. It won't be multilib, but that's OK. This > should allow you to build with what's hot as of an hour ago. I am very happy to hear that! Mamoru From notting at redhat.com Fri May 4 16:12:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 4 May 2007 12:12:42 -0400 Subject: PPC64 builds (was Re: Merge Status - Building available) In-Reply-To: <1178258180.11120.252.camel@pmac.infradead.org> References: <200705031416.00604.jkeating@redhat.com> <200705032158.32153.ville.skytta@iki.fi> <200705031545.56868.jkeating@redhat.com> <1178258180.11120.252.camel@pmac.infradead.org> Message-ID: <20070504161242.GA31650@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > On Thu, 2007-05-03 at 15:45 -0400, Jesse Keating wrote: > > Egads. We had thought about this at one point, and it seems to have slipped > > our collective minds. Many things will be able to build, but some thing that > > require previously Extras packages in the buildroot will fail. I've setup a > > tracker bug to track these. If your package fails to build, please file a > > bug for it and block 'PPC64MissingDeps'. We will be trying to fix these > > asap, by bootstrapping and rebuilding ex-Extras packages to generate a ppc64 > > build of them. If at all possible, please do not ExcludeArch: ppc64. > > And if you do ExcludeArch: ppc64 remember that _ALL_ uses of > ExcludeArch: must have a corresponding bug filed, even if it's just an > explanation. And that bug must be on the corresponding ExcludeArch > tracker bug. I've created the tracker bug (#238953) for ppc64 -- aliased > 'FE-ExcludeArch-ppc64' for consistency with the others, which will all > probably drop the leading 'FE-' from the name at some point. > > We _really_ ought to start enforcing this "ExcludeArch must have bug" > rule in the build system. Well, anything that requires mono can probably piggyback on 238950, as opposed to having its own separate one. Bill From giallu at gmail.com Fri May 4 16:14:35 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 4 May 2007 18:14:35 +0200 Subject: Merge Status - Building available In-Reply-To: <1178290819.3026.172.camel@zod.rchland.ibm.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <1178290819.3026.172.camel@zod.rchland.ibm.com> Message-ID: On 5/4/07, Josh Boyer wrote: > > I'm not sure if this was asked in the past but... Is there an easy way > > to tell if one your packages are included in one or more of the > > collections? > > By collections do you mean "spins"? Or tags? The list of package > builds included in the f7-final tag can be viewed via: > > http://koji.fedoraproject.org/koji/packages?tagID=10 I meant spins, but this is fine as well. thank you From jkeating at redhat.com Fri May 4 16:09:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 09:09:56 -0700 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <1178290819.3026.172.camel@zod.rchland.ibm.com> Message-ID: <200705040909.57112.jkeating@redhat.com> On Friday 04 May 2007 09:14:35 Gianluca Sforna wrote: > I meant spins, but this is fine as well. > thank you What goes in the spins isn't really tracked in koji, as it is somewhat dynamic depending on dep resolution. I need to make the working manifest files for pungi available in a public repo, just not sure where yet (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Fri May 4 16:19:59 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 04 May 2007 12:19:59 -0400 Subject: Suggestion: a list for important announcements In-Reply-To: <200705040901.44127.jkeating@redhat.com> References: <200705041155.22189.nomis80@nomis80.org> <200705040901.44127.jkeating@redhat.com> Message-ID: <463B5D2F.8010201@redhat.com> Jesse Keating wrote: > On Friday 04 May 2007 08:55:21 Simon Perreault wrote: >> Here's a suggestion: create a list, say >> fedora-maintainers-announce at redhat.com, where only core people would have >> the right to post. These posts would be important announcements like "ok >> people, feature freeze for the next 3 weeks" or "please rebuild if XYZ >> affects you". Posts to this list would always be cross-posted to >> fedora-maintainers, where ensuing discussion could take place. >> >> This is inspired from a similar scheme used for KDE development. > > We have that, sortof. We just haven't kicked it into gear yet. Unfortunately > with such a list you miss out on a lot of the dialog and discussion that > happens around such announcements, like all the general discussion and usage > suggestions for koji. You'd get the announcement that we're using koji... > and not much else. > Well, I do agree that there's alot of discussion on here that should go on fedora-devel. The firefox langpacks mess for example. From jspaleta at gmail.com Fri May 4 16:22:41 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 May 2007 08:22:41 -0800 Subject: koji queue vs plague queue behaviour In-Reply-To: <200705040835.48057.jkeating@redhat.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <604aa7910705032159t24686f38w42b1ec2a5a5cc9ad@mail.gmail.com> <200705040835.48057.jkeating@redhat.com> Message-ID: <604aa7910705040922o736b6da0hf7888a184153540@mail.gmail.com> On 5/4/07, Jesse Keating wrote: > XMLRPC is your friend. I've learn the hard way, that XMLRPC really wants to be my friend, but when we get to talking at a party or whatever we quickly find we don't really have that much in common, so its just several minutes of awkward silence punctuated by brief attempts to start a conversation with a new subject and just not connecting. It's not like we hate either other.. I mean if XMLRPC was a redsox fan and I was a yankees fan then at least we'd have a common reason to argue, but we can't even seem to find a negative correlated interest. So we end up talking about the weather or some other pointless task, that really isn't substantial nor worth the effort. -jef"if anyone has any good suggestions for reading material for how to write simple linux kernel level device drivers for pci hardware, I'd appreciate some pointers. I might need to learn how to do it for some digital i/o boards for my new job"spaleta From jkeating at redhat.com Fri May 4 16:20:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 May 2007 09:20:18 -0700 Subject: Suggestion: a list for important announcements In-Reply-To: <463B5D2F.8010201@redhat.com> References: <200705041155.22189.nomis80@nomis80.org> <200705040901.44127.jkeating@redhat.com> <463B5D2F.8010201@redhat.com> Message-ID: <200705040920.18479.jkeating@redhat.com> On Friday 04 May 2007 09:19:59 Christopher Aillon wrote: > Well, I do agree that there's alot of discussion on here that should go > on fedora-devel. ?The firefox langpacks mess for example. Absolutely. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri May 4 16:38:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 04 May 2007 18:38:05 +0200 Subject: Suggestion: a list for important announcements In-Reply-To: <200705040920.18479.jkeating@redhat.com> References: <200705041155.22189.nomis80@nomis80.org> <200705040901.44127.jkeating@redhat.com> <463B5D2F.8010201@redhat.com> <200705040920.18479.jkeating@redhat.com> Message-ID: <463B616D.7030700@leemhuis.info> Jesse Keating schrieb: > On Friday 04 May 2007 09:19:59 Christopher Aillon wrote: >> Well, I do agree that there's alot of discussion on here that should go >> on fedora-devel. The firefox langpacks mess for example. > Absolutely. +1 Just FYI, the new layout of the mailing list reorganization that was discussed weeks/months ago (see http://fedoraproject.org/wiki/ThorstenLeemhuis/MailingListReorganization for latest proposal) will hopefully solve problems like this. But the reorganisation was put on hold as we wait for hardware to get in place. When that happend *and* F7 is ready I'll get that topic up for public discussion again. CU thl From j.w.r.degoede at hhs.nl Fri May 4 17:03:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 May 2007 19:03:52 +0200 Subject: koji queue vs plague queue behaviour In-Reply-To: <604aa7910705040922o736b6da0hf7888a184153540@mail.gmail.com> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <604aa7910705032159t24686f38w42b1ec2a5a5cc9ad@mail.gmail.com> <200705040835.48057.jkeating@redhat.com> <604aa7910705040922o736b6da0hf7888a184153540@mail.gmail.com> Message-ID: <463B6778.1090807@hhs.nl> OT: > -jef"if anyone has any good suggestions for reading material for how > to write simple linux kernel level device drivers for pci hardware, > I'd appreciate some pointers. I might need to learn how to do it for > some digital i/o boards for my new job"spaleta > Linux Device Drivers 3rd edition by Corbet, GKH et all is a good book to start with. Regards, Hans p.s. Do those happen to be 8255 based io boards? I have some code laying around for those. From tjanouse at redhat.com Fri May 4 17:41:40 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 4 May 2007 19:41:40 +0200 Subject: Status of the merge In-Reply-To: <1178293061.2785.4.camel@aglarond.local> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> <20070504105426.GA11699@redhat.com> <1178293061.2785.4.camel@aglarond.local> Message-ID: <20070504174140.GA17225@redhat.com> On Fri, May 04, 2007 at 11:37:41AM -0400, Jeremy Katz wrote: > > For all who use private branches, the following patch may be helpful. I added > > it to RH's Makefile.common recently, being inspired by `make zstreams'. > > This seems okay, but can you also add appropriate documentation to the > help target? Sorry, new patch: diff -u -r1.54 Makefile.common --- Makefile.common 4 May 2007 15:39:29 -0000 1.54 +++ Makefile.common 4 May 2007 17:40:26 -0000 @@ -459,6 +459,7 @@ @echo " patch SUFFIX= Create and add a gendiff patch file" @echo " rediff SUFFIX= Recreates a gendiff patch file, retaining comments" @echo " unused-patches Print list of patches not referenced by name in specfile" + @echo " privates Checkout \"private--branch\" branches into ../$(BRANCH)-" @echo " gimmespec Print the name of the specfile" gimmespec: @@ -467,6 +468,28 @@ unused-patches: @for f in *.patch; do if [ -e $$f ]; then grep -q $$f $(SPECFILE) || echo $$f; fi; done +privates: $(SPECFILE) + @for P_BRANCH in $$(cvs -f log -h $(SPECFILE) | awk '/private-.*-branch/ { print substr($$1, 0, length($$1) - 1) }'); do \ + P_DIR=$${P_BRANCH%-branch}; \ + P_DIR=$${P_DIR#private-}; \ + P_DIR=$(BRANCH)-$${P_DIR}; \ + pushd .. > /dev/null; \ + if [ -d $$P_DIR ]; then \ + cd $$P_DIR; \ + if [ ! -f CVS/Tag ] || [ $$(cat CVS/Tag) != "T$$P_BRANCH" ]; then \ + echo "$$P_DIR exists but is not on branch $$P_BRANCH"; \ + exit 1; \ + else \ + echo "Updating $$P_DIR..."; \ + cvs up; \ + fi; \ + else \ + echo "Checking out $$P_BRANCH into $$P_DIR..."; \ + cvs co -r $$P_BRANCH -d $$P_DIR rpms/$(NAME)/$(BRANCH); \ + fi; \ + popd > /dev/null; \ + done + ##################### EXPERIMENTAL ########################## # this stuff is very experimental in nature and should not be # relied upon until these targets are moved above this line -- TJ. (Brno, CZ), BaseOS, Red Hat From nomis80 at nomis80.org Fri May 4 18:12:30 2007 From: nomis80 at nomis80.org (Simon Perreault) Date: Fri, 4 May 2007 14:12:30 -0400 Subject: Suggestion: a list for important announcements In-Reply-To: <200705040901.44127.jkeating@redhat.com> References: <200705041155.22189.nomis80@nomis80.org> <200705040901.44127.jkeating@redhat.com> Message-ID: <200705041412.31085.nomis80@nomis80.org> On Friday 04 May 2007 12:01, Jesse Keating wrote: > Unfortunately with such a list you miss out on a lot of the dialog and > discussion that happens around such announcements, like all the general > discussion and usage suggestions for koji. You'd get the announcement that > we're using koji... and not much else. Ironically, I didn't know what koji was. It got lost in the noise. I would prefer to only get the announcement, while knowing that there's this other mailing list I can go to if I need more info. From jspaleta at gmail.com Fri May 4 19:06:11 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 May 2007 11:06:11 -0800 Subject: koji queue vs plague queue behaviour In-Reply-To: <463B6778.1090807@hhs.nl> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <604aa7910705032159t24686f38w42b1ec2a5a5cc9ad@mail.gmail.com> <200705040835.48057.jkeating@redhat.com> <604aa7910705040922o736b6da0hf7888a184153540@mail.gmail.com> <463B6778.1090807@hhs.nl> Message-ID: <604aa7910705041206t62a6c1ddn8bbd85ab496fde62@mail.gmail.com> On 5/4/07, Hans de Goede wrote: > OT: -jef"oops sorry should have said off list in that sig.. didnt mean to hijack a thread."spaleta From dwmw2 at infradead.org Fri May 4 20:36:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 04 May 2007 21:36:31 +0100 Subject: PPC64 builds (was Re: Merge Status - Building available) In-Reply-To: <20070504161242.GA31650@nostromo.devel.redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705032158.32153.ville.skytta@iki.fi> <200705031545.56868.jkeating@redhat.com> <1178258180.11120.252.camel@pmac.infradead.org> <20070504161242.GA31650@nostromo.devel.redhat.com> Message-ID: <1178310992.17680.18.camel@shinybook.infradead.org> On Fri, 2007-05-04 at 12:12 -0400, Bill Nottingham wrote: > Well, anything that requires mono can probably piggyback on 238950, > as opposed to having its own separate one. That makes sense, as long as we can find the packages when we want to turn them on again (hell, I did firefox/ppc64 and that was as pointless as mono is). Having separate bugs which _depend_ on 238950 might be better. -- dwmw2 From mattdm at mattdm.org Sat May 5 01:22:08 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 4 May 2007 21:22:08 -0400 Subject: [F8/multilib] {,/usr}/{,s}bin64 In-Reply-To: <1178022865.13694.24.camel@aglarond.local> References: <20070426111325.GH23704@neu.nirvana> <1177589263.2755.365.camel@pmac.infradead.org> <20070426171648.GB7127@neu.nirvana> <20070427145010.GE20840@ryvius.pekin.waw.pl> <20070427145517.GB3031@free.fr> <46321284.1030604@odu.neva.ru> <20070427151404.GC3031@free.fr> <20070501042703.GC11331@nostromo.devel.redhat.com> <20070501110346.GA17476@jadzia.bu.edu> <1178022865.13694.24.camel@aglarond.local> Message-ID: <20070505012208.GA15210@jadzia.bu.edu> On Tue, May 01, 2007 at 08:34:25AM -0400, Jeremy Katz wrote: > There's a lot of lower power devices which are still 32-bit only and are > going to be for quite a while as far as I can see. And being able to > trivially build for them is one of the reasons why you go for x86 for > them instead of an embedded specific chip like an arm or a mips. > The compatibility and the fact that it's all but entirely transparent is > a huge part of the value of the x86->x86_64 transition. But couldn't we make a chrooted build environment near-transparent too? Then it'd have those advantages on all architectures, *for* all architectures -- and for craziness like mingw32 -- without causing massive complexity for the normal server or desktop case. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at camperquake.de Sat May 5 11:08:48 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 5 May 2007 13:08:48 +0200 Subject: koji queue vs plague queue behaviour In-Reply-To: <463B6778.1090807@hhs.nl> References: <7dd7ab490705032038v224bdce8v10cf6c2ceb6dbee0@mail.gmail.com> <200705032042.41188.jkeating@redhat.com> <604aa7910705032159t24686f38w42b1ec2a5a5cc9ad@mail.gmail.com> <200705040835.48057.jkeating@redhat.com> <604aa7910705040922o736b6da0hf7888a184153540@mail.gmail.com> <463B6778.1090807@hhs.nl> Message-ID: <20070505130848.3c3d501f@lain.camperquake.de> Hi. On Fri, 04 May 2007 19:03:52 +0200, Hans de Goede wrote > Linux Device Drivers 3rd edition by Corbet, GKH et all is a good book > to start with. And "Understanding the Linux Kernel" (also third edition) if you are interested in the "why" in addition to the "how". Please note that both books cover the 2.6 kernel around the 2.6.11 release (more or less), and that things may have changed quite a bit on the way to 2.6.21. Nonetheless, the ground work covered is invaluable. From ville.skytta at iki.fi Sat May 5 20:37:56 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 5 May 2007 23:37:56 +0300 Subject: Merge Status - Building available In-Reply-To: <1178285694.3026.166.camel@zod.rchland.ibm.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> Message-ID: <200705052337.56897.ville.skytta@iki.fi> On Friday 04 May 2007, Josh Boyer wrote: > On Fri, 2007-05-04 at 22:33 +0900, Mamoru Tasaka wrote: > > Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: > > > Koji will take your build and run with it, you'll see some output on > > > the CLI. Your build, if successful, will be tagged with 'dist-fc7'. > > > This is not enough to get it into rawhide, as F7 is in continual slush > > > freeze. If you need your build to get into rawhide and thus Fedora 7, > > > you need to follow the policy > > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > here. Hm. So let's say I update and build an ex-Extras package in the devel branch. I don't contact rel-eng so it won't get into Rawhide nor F7 per the above. The question is where _will_ it end up in this scenario? > > A. Does this mean that many packages which were approved and were > > rebuilt after koji began to work (then marked as 'dist-fc7') > > will not be pushed into Fedora 7, > > while they will be pushed into Fedora _Extras_ 6/5 as before (usually > > within two days)? (i.e. will this cause the situation that > > newer packages will appear on FE-5/6, but not on Fedora 7)? > > Unless you submit a request to rel-eng, yes. You need to have those > packages tagged as f7-final if you want them in the release. What if I have some packages meeting the A) status above, and I don't care that deeply whether they're in the F7 release but sure do want them in F7 repositories as soon as possible after the release; do I need to do something? From ville.skytta at iki.fi Sat May 5 21:00:04 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 6 May 2007 00:00:04 +0300 Subject: Merge/F7 questions Message-ID: <200705060000.04269.ville.skytta@iki.fi> Hi, some questions about the merge and F7: 1) When will the EVR of the kernel to be included in the F7 final release be known, and will there be time to build module packages for it and get them through rel-eng? 2) How can I get the modules built for the f7-final kernel? I just tried it with em8300-kmod; "koji latest-pkg f7-final kernel" says kernel-2.6.21-1.3116.fc7 at the moment, but I can no longer build modules for it as those 1.3116.fc7 kernel(-devel) packages don't seem to be available for the builders: https://koji.fedoraproject.org/koji/taskinfo?taskID=3364 3) The new mirror layout at http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge does not show an "updates" directory for F7, nor mentions what replaces it. Was its omission from the new layout intentional? If yes, where do package updates go from F7 on? From dominik at greysector.net Sat May 5 21:49:26 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sat, 5 May 2007 23:49:26 +0200 Subject: Merge Status - Building available In-Reply-To: <200705052337.56897.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> Message-ID: <20070505214926.GA11093@ryvius.pekin.waw.pl> On Saturday, 05 May 2007 at 22:37, Ville Skytt? wrote: > On Friday 04 May 2007, Josh Boyer wrote: > > On Fri, 2007-05-04 at 22:33 +0900, Mamoru Tasaka wrote: > > > Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: > > > > Koji will take your build and run with it, you'll see some output on > > > > the CLI. Your build, if successful, will be tagged with 'dist-fc7'. > > > > This is not enough to get it into rawhide, as F7 is in continual slush > > > > freeze. If you need your build to get into rawhide and thus Fedora 7, > > > > you need to follow the policy > > > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > > here. > > Hm. So let's say I update and build an ex-Extras package in the devel branch. > I don't contact rel-eng so it won't get into Rawhide nor F7 per the above. > The question is where _will_ it end up in this scenario? Good question! I have another: how do I check which versions of my packages are going to be in F7? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From notting at redhat.com Sun May 6 04:28:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Sun, 6 May 2007 00:28:42 -0400 Subject: Merge Status - Building available In-Reply-To: <20070505214926.GA11093@ryvius.pekin.waw.pl> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> Message-ID: <20070506042842.GA20972@nostromo.devel.redhat.com> Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: > I have another: how do I check which versions of my packages are going to > be in F7? koji latest-pkg f7-final Bill From dominik at greysector.net Sun May 6 14:15:32 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 May 2007 16:15:32 +0200 Subject: Merge Status - Building available In-Reply-To: <20070506042842.GA20972@nostromo.devel.redhat.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> Message-ID: <20070506141532.GA6877@ryvius.pekin.waw.pl> On Sunday, 06 May 2007 at 06:28, Bill Nottingham wrote: > Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: > > I have another: how do I check which versions of my packages are going to > > be in F7? > > koji latest-pkg f7-final Thank you. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mr.ecik at gmail.com Sun May 6 17:20:52 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 6 May 2007 19:20:52 +0200 Subject: Merge Status - Building available In-Reply-To: <20070506042842.GA20972@nostromo.devel.redhat.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> Message-ID: <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> 2007/5/6, Bill Nottingham : > koji latest-pkg f7-final > I've just used it to check all my packages and it turned out that two of my packages have fc6 dist tag: [ecik at ecik ~]$ koji latest-pkg f7-final bygfoot kadu-theme Build Tag Built by ---------------------------------------- -------------------- ---------------- bygfoot-2.0.1-1.fc6 fe7-merge jkeating kadu-theme-0.5.0-2.fc6 fe7-merge jkeating Is it intended? -- Micha? Bentkowski mr.ecik at gmail.com From bugs.michael at gmx.net Sun May 6 17:42:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 6 May 2007 19:42:37 +0200 Subject: Merge Status - Building available In-Reply-To: <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> Message-ID: <20070506194237.fb02273e.bugs.michael@gmx.net> On Sun, 6 May 2007 19:20:52 +0200, Micha? Bentkowski wrote: > 2007/5/6, Bill Nottingham : > > koji latest-pkg f7-final > > > > I've just used it to check all my packages and it turned out that two > of my packages have fc6 dist tag: > > [ecik at ecik ~]$ koji latest-pkg f7-final bygfoot kadu-theme > Build Tag Built by > ---------------------------------------- -------------------- ---------------- > bygfoot-2.0.1-1.fc6 fe7-merge jkeating > kadu-theme-0.5.0-2.fc6 fe7-merge jkeating > > Is it intended? Yes, since you haven't touched/rebuilt your packages for Fedora 7 yet. Perhaps because no update was needed so far. You can tell. ;) Hence Fedora Extras Development started with copies of the Fedora Extras 6 packages, and that is what you see in the repository whenever a package has not been updated. Many other packages have a fc6 dist tag, because they haven't been updated either. The "Built by jkeating" is misleading, since Jesse only added the existing packages from the repository to koji's database without (re-)building them actually. From mr.ecik at gmail.com Sun May 6 17:55:22 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 6 May 2007 19:55:22 +0200 Subject: Merge Status - Building available In-Reply-To: <20070506194237.fb02273e.bugs.michael@gmx.net> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> Message-ID: <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> 2007/5/6, Michael Schwendt : > Yes, since you haven't touched/rebuilt your packages for Fedora 7 yet. Fine, thanks :) So are we supposed to rebuild these packages now? Or the mass rebuild will be announced soon? (sorry if it's a silly question, because I've not tracked lists recently) -- Micha? Bentkowski mr.ecik at gmail.com From tibbs at math.uh.edu Sun May 6 17:56:57 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 May 2007 12:56:57 -0500 Subject: Merge Status - Building available In-Reply-To: <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> Message-ID: >>>>> "MB" == Micha? Bentkowski writes: MB> I've just used it to check all my packages and it turned out that MB> two of my packages have fc6 dist tag: Have you ever built them for the development tree? If they haven't been rebuilt, they'll just be copies of the packages that were built for FC6. - J< From tibbs at math.uh.edu Sun May 6 17:59:06 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 May 2007 12:59:06 -0500 Subject: Merge Status - Building available In-Reply-To: <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> Message-ID: >>>>> "MB" == Micha? Bentkowski writes: MB> 2007/5/6, Michael Schwendt : >> Yes, since you haven't touched/rebuilt your packages for Fedora 7 >> yet. MB> So are we supposed to rebuild these packages now? Only if you have some reason to rebuild them. MB> Or the mass rebuild will be announced soon? What mass rebuild? Nothing has happened that would require one. - J< From mr.ecik at gmail.com Sun May 6 18:01:30 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 6 May 2007 20:01:30 +0200 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> Message-ID: <668bb39a0705061101q51be2d14vf48c10ed4acaf56e@mail.gmail.com> 06 May 2007 12:56:57 -0500, Jason L Tibbitts III : > Have you ever built them for the development tree? If they haven't > been rebuilt, they'll just be copies of the packages that were built > for FC6. They were last built for devel when fc6 was a development branch. -- Micha? Bentkowski mr.ecik at gmail.com From mr.ecik at gmail.com Sun May 6 18:03:14 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 6 May 2007 20:03:14 +0200 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> Message-ID: <668bb39a0705061103y34d5b1d3n96ce780f01e36a22@mail.gmail.com> 06 May 2007 12:59:06 -0500, Jason L Tibbitts III : > What mass rebuild? Nothing has happened that would require one. I'm asking because as far as I remember there were mass rebuild for FC6 and FC5. -- Micha? Bentkowski mr.ecik at gmail.com From tibbs at math.uh.edu Sun May 6 18:05:50 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 May 2007 13:05:50 -0500 Subject: Merge Status - Building available In-Reply-To: <668bb39a0705061103y34d5b1d3n96ce780f01e36a22@mail.gmail.com> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> <668bb39a0705061103y34d5b1d3n96ce780f01e36a22@mail.gmail.com> Message-ID: >>>>> "MB" == Micha? Bentkowski writes: MB> I'm asking because as far as I remember there were mass rebuild MB> for FC6 and FC5. Yes, due to things like GCC changes which required them. - J< From mtasaka at ioa.s.u-tokyo.ac.jp Sun May 6 18:06:08 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 07 May 2007 03:06:08 +0900 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> Message-ID: <463E1910.8010409@ioa.s.u-tokyo.ac.jp> Jason L Tibbitts III wrote, at 05/07/2007 02:59 AM +9:00: >>>>>> "MB" == Micha? Bentkowski writes: > > MB> 2007/5/6, Michael Schwendt : >>> Yes, since you haven't touched/rebuilt your packages for Fedora 7 >>> yet. > > MB> So are we supposed to rebuild these packages now? > > Only if you have some reason to rebuild them. > > MB> Or the mass rebuild will be announced soon? > > What mass rebuild? Nothing has happened that would require one. > I have rebuilt all arch-dependent rpms to support ppc64. Mamoru From mr.ecik at gmail.com Sun May 6 18:09:07 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 6 May 2007 20:09:07 +0200 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> <668bb39a0705061103y34d5b1d3n96ce780f01e36a22@mail.gmail.com> Message-ID: <668bb39a0705061109j49c9cc9bh2f9d83d69975ba6a@mail.gmail.com> 06 May 2007 13:05:50 -0500, Jason L Tibbitts III : > Yes, due to things like GCC changes which required them. Right, forgot that. Thanks for clarify things. -- Micha? Bentkowski mr.ecik at gmail.com From mszpak at wp.pl Sun May 6 18:17:25 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Sun, 06 May 2007 20:17:25 +0200 Subject: Merge Status - Building available In-Reply-To: <200705031416.00604.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> Message-ID: <463E1BB5.5040101@wp.pl> On 2007-05-03 20:15:57 +0200, Jesse Keating wrote: > It is now possible to do builds for devel/. > > 'make build' from a checkout will do the right thing, provided you've > installed koji from extras and ran the setup utility. See > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge/FAQ >From FAQ: > The "devel" branch uses koji instead of plague. Please follow these > steps to setup your client for koji. > yum install koji Is there any particular reason why koji isn't available in Extras for FC5? I didn't have any problems with using plague on that system. Marcin > Koji will take your build and run with it, you'll see some output on the CLI. > Your build, if successful, will be tagged with 'dist-fc7'. This is not > enough to get it into rawhide, as F7 is in continual slush freeze. If you > need your build to get into rawhide and thus Fedora 7, you need to follow the > policy http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > here. > > Rawhide (once we get that going again) will compose from the 'f7-final' tag. From jkeating at redhat.com Sun May 6 18:25:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 6 May 2007 11:25:10 -0700 Subject: Merge Status - Building available In-Reply-To: <463E1BB5.5040101@wp.pl> References: <200705031416.00604.jkeating@redhat.com> <463E1BB5.5040101@wp.pl> Message-ID: <200705061125.13876.jkeating@redhat.com> On Sunday 06 May 2007 11:17:25 Marcin Zaj?czkowski wrote: > Is there any particular reason why koji isn't available in Extras for FC5? > I didn't have any problems with using plague on that system. Mostly me not building there yet. python-krb5 needs to be built on FC-5 as well, then I should be able to build koji there, as well as on EPEL5. I'll be working on that hopefully Monday. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mszpak at wp.pl Sun May 6 19:20:18 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Sun, 06 May 2007 21:20:18 +0200 Subject: Merge Status - Building available In-Reply-To: <200705061125.13876.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <463E1BB5.5040101@wp.pl> <200705061125.13876.jkeating@redhat.com> Message-ID: <463E2A72.90203@wp.pl> On 2007-05-06 20:25:10 +0200, Jesse Keating wrote: > On Sunday 06 May 2007 11:17:25 Marcin Zaj?czkowski wrote: >> Is there any particular reason why koji isn't available in Extras for FC5? >> I didn't have any problems with using plague on that system. > > Mostly me not building there yet. python-krb5 needs to be built on FC-5 as > well, then I should be able to build koji there, as well as on EPEL5. I'll > be working on that hopefully Monday. It would be nice. I have FC6 only on my laptop which I don't use often. I think a few more Fedora contributors have FC5 as their development box (using to "upload" the new packages). Regards Marcin From opensource at till.name Sun May 6 19:26:30 2007 From: opensource at till.name (Till Maas) Date: Sun, 06 May 2007 21:26:30 +0200 Subject: Makefile: URL to nonexistant wiki page when koji is missing Message-ID: <200705062126.31627.opensource@till.name> Hiyas, when I run make build withou having koji installed I get the following error: Must have koji installed - see http://fedoraproject.org/wiki/BuildSystemClientSetup make: *** [koji] Fehler 1 http://fedoraproject.org/wiki/BuildSystemClientSetup is an empty page, so this should be fixed. I do not know which page it should be, http://fedoraproject.org/wiki/PackageMaintainers/BuildSystemClientSetup only mentions plague. Maybe it is this page: http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge/FAQ Regards, Till From tibbs at math.uh.edu Mon May 7 01:04:40 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 May 2007 20:04:40 -0500 Subject: Merge Status - Building available In-Reply-To: <463E2A72.90203@wp.pl> References: <200705031416.00604.jkeating@redhat.com> <463E1BB5.5040101@wp.pl> <200705061125.13876.jkeating@redhat.com> <463E2A72.90203@wp.pl> Message-ID: >>>>> "MZ" == Marcin Zaj?czkowski writes: MZ> It would be nice. It's also really easy to build python-krbV and koji for FC5; takes a couple of minutes at most to do two CVS checkouts and run a couple of makes. I guess if you're competent enough to need koji and you need it before Jesse can get it built, not having it in the repo shouldn't be much of an impediment. - J< From dakingun at gmail.com Mon May 7 01:16:16 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Sun, 6 May 2007 21:16:16 -0400 Subject: Merge Status - Building available In-Reply-To: <463E1910.8010409@ioa.s.u-tokyo.ac.jp> References: <200705031416.00604.jkeating@redhat.com> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> <463E1910.8010409@ioa.s.u-tokyo.ac.jp> Message-ID: On 5/6/07, Mamoru Tasaka wrote: > > I have rebuilt all arch-dependent rpms to support ppc64. > But strigi builds are still failing because cmake and cppunit-devel are not available for ppc64. > Mamoru > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From notting at redhat.com Mon May 7 04:27:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 May 2007 00:27:38 -0400 Subject: Merge Status - Building available In-Reply-To: References: <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> <463E1910.8010409@ioa.s.u-tokyo.ac.jp> Message-ID: <20070507042738.GD29442@nostromo.devel.redhat.com> Deji Akingunola (dakingun at gmail.com) said: > On 5/6/07, Mamoru Tasaka wrote: > > > > >I have rebuilt all arch-dependent rpms to support ppc64. > > > But strigi builds are still failing because cmake and cppunit-devel > are not available for ppc64. 'We're working on it.' Bill From notting at redhat.com Mon May 7 04:31:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 May 2007 00:31:01 -0400 Subject: Merge Status - Building available In-Reply-To: <20070507042738.GD29442@nostromo.devel.redhat.com> References: <200705052337.56897.ville.skytta@iki.fi> <20070505214926.GA11093@ryvius.pekin.waw.pl> <20070506042842.GA20972@nostromo.devel.redhat.com> <668bb39a0705061020y66ca79eape7323176af21db5b@mail.gmail.com> <20070506194237.fb02273e.bugs.michael@gmx.net> <668bb39a0705061055t4c5c231u934b1784d3f4ceb0@mail.gmail.com> <463E1910.8010409@ioa.s.u-tokyo.ac.jp> <20070507042738.GD29442@nostromo.devel.redhat.com> Message-ID: <20070507043101.GE29442@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Deji Akingunola (dakingun at gmail.com) said: > > On 5/6/07, Mamoru Tasaka wrote: > > > > > > > >I have rebuilt all arch-dependent rpms to support ppc64. > > > > > But strigi builds are still failing because cmake and cppunit-devel > > are not available for ppc64. > > 'We're working on it.' Sorry, unnecessarily terse. We're working on importing ppc64 builds of extras into koji. We have slightly under 1000 source RPMs *built*, but the import process itself is going rather slowly. Both cmake and cppunit should show up eventually. Bill From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 7 11:09:34 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 07 May 2007 20:09:34 +0900 Subject: koji refuses to build my new packages Message-ID: <463F08EE.2040608@ioa.s.u-tokyo.ac.jp> Hello. I am trying to rebuild my package accepted yesterday (in Japan) "ruby-amazon" on koji several times but all them failed as below: -------------------------------------------------------- [tasaka1 at localhost devel]$ make build Created task: 4054 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4054 Watching tasks (this may be safely interrupted)... 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): free 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): free -> open (xenbuilder4.fedora.phx.redhat.com) 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): free 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): free -> open (ppc2.fedora.redhat.com) 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): open (ppc2.fedora.redhat.com) -> closed 0 free 1 open 1 done 0 failed 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): open (xenbuilder4.fedora.phx.redhat.com) -> FAILED: BuildError: package ruby-amazon not in list for tag dist-fc7 0 free 0 open 1 done 1 failed make: *** [koji] ??? 1 ------------------------------------------------------- ("???" means "error") http://koji.fedoraproject.org/koji/taskinfo?taskID=4054 There seem to be several similar packages which failed to build (not my packages) http://koji.fedoraproject.org/koji/taskinfo?taskID=4007 http://koji.fedoraproject.org/koji/taskinfo?taskID=4003 Help?? Mamoru From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 7 11:12:53 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 07 May 2007 20:12:53 +0900 Subject: Merge Status - Building available In-Reply-To: <200705052337.56897.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> Message-ID: <463F09B5.2010902@ioa.s.u-tokyo.ac.jp> Ville Skytt? wrote, at 05/06/2007 05:37 AM +9:00: > On Friday 04 May 2007, Josh Boyer wrote: >> On Fri, 2007-05-04 at 22:33 +0900, Mamoru Tasaka wrote: >>> Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: >>>> Koji will take your build and run with it, you'll see some output on >>>> the CLI. Your build, if successful, will be tagged with 'dist-fc7'. >>>> This is not enough to get it into rawhide, as F7 is in continual slush >>>> freeze. If you need your build to get into rawhide and thus Fedora 7, >>>> you need to follow the policy >>>> http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy >>>> here. > > Hm. So let's say I update and build an ex-Extras package in the devel branch. > I don't contact rel-eng so it won't get into Rawhide nor F7 per the above. > The question is where _will_ it end up in this scenario? > >>> A. Does this mean that many packages which were approved and were >>> rebuilt after koji began to work (then marked as 'dist-fc7') >>> will not be pushed into Fedora 7, >>> while they will be pushed into Fedora _Extras_ 6/5 as before (usually >>> within two days)? (i.e. will this cause the situation that >>> newer packages will appear on FE-5/6, but not on Fedora 7)? >> Unless you submit a request to rel-eng, yes. You need to have those >> packages tagged as f7-final if you want them in the release. > > What if I have some packages meeting the A) status above, and I don't care > that deeply whether they're in the F7 release but sure do want them in F7 > repositories as soon as possible after the release; do I need to do > something? Also I want to know about this. Mamoru From jonathan.underwood at gmail.com Mon May 7 11:27:11 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 12:27:11 +0100 Subject: Packaging Draft for Emacs add-on packages Message-ID: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> Dear All, I have created a draft Packaging Guide for Emacs add-on packages here: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns Any comments or suggestions greatfully received. There are a couple of spec file templates included which I hope will be useful. I'd like to get this added to the packaging notes fairly soon - presumably this requires FESCO ratification? While putting this together, I noticed that there's an awful lot of useful information in PackagingDrafts pages. Perhaps we should have a day focussed on getting packaging drafts finished, approved and added to the Packaging documentation. Thoughts? Jonathan. From dev at nigelj.com Mon May 7 11:27:13 2007 From: dev at nigelj.com (Nigel Jones) Date: Mon, 07 May 2007 23:27:13 +1200 Subject: koji refuses to build my new packages In-Reply-To: <463F08EE.2040608@ioa.s.u-tokyo.ac.jp> References: <463F08EE.2040608@ioa.s.u-tokyo.ac.jp> Message-ID: <463F0D11.1030003@nigelj.com> Mamoru Tasaka wrote: > Hello. > > I am trying to rebuild my package accepted yesterday (in Japan) > "ruby-amazon" on koji several times but all them failed as below: > -------------------------------------------------------- > [tasaka1 at localhost devel]$ make build > Created task: 4054 > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4054 > Watching tasks (this may be safely interrupted)... > 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): free > 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): free -> open > (xenbuilder4.fedora.phx.redhat.com) > 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): free > 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): free -> open (ppc2.fedora.redhat.com) > 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): open (ppc2.fedora.redhat.com) -> > closed > 0 free 1 open 1 done 0 failed > 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): open > (xenbuilder4.fedora.phx.redhat.com) -> FAILED: BuildError: package ruby-amazon not in list > for tag dist-fc7 > 0 free 0 open 1 done 1 failed > make: *** [koji] ??? 1 > ------------------------------------------------------- > ("???" means "error") > http://koji.fedoraproject.org/koji/taskinfo?taskID=4054 > > There seem to be several similar packages which failed to build > (not my packages) > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4007 > http://koji.fedoraproject.org/koji/taskinfo?taskID=4003 > > Help?? Simple answer: Warren seems to have accidentally not added the latest batch of CVS additions to Koji. I've poked him and the guys in #fedora-admin on IRC to take a look. N.J. > > Mamoru > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jwboyer at jdub.homelinux.org Mon May 7 12:02:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 07:02:45 -0500 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> Message-ID: <1178539365.2990.4.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 12:27 +0100, Jonathan Underwood wrote: > Dear All, > > I have created a draft Packaging Guide for Emacs add-on packages here: > > http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns > > Any comments or suggestions greatfully received. There are a couple of > spec file templates included which I hope will be useful. > > I'd like to get this added to the packaging notes fairly soon - > presumably this requires FESCO ratification? Actually, it needs to go to the Packaging Committee. josh From jwboyer at jdub.homelinux.org Mon May 7 12:04:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 07:04:07 -0500 Subject: koji refuses to build my new packages In-Reply-To: <463F0D11.1030003@nigelj.com> References: <463F08EE.2040608@ioa.s.u-tokyo.ac.jp> <463F0D11.1030003@nigelj.com> Message-ID: <1178539447.2990.6.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 23:27 +1200, Nigel Jones wrote: > Mamoru Tasaka wrote: > > Hello. > > > > I am trying to rebuild my package accepted yesterday (in Japan) > > "ruby-amazon" on koji several times but all them failed as below: > > -------------------------------------------------------- > > [tasaka1 at localhost devel]$ make build > > Created task: 4054 > > Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4054 > > Watching tasks (this may be safely interrupted)... > > 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): free > > 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): free -> open > > (xenbuilder4.fedora.phx.redhat.com) > > 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): free > > 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): free -> open (ppc2.fedora.redhat.com) > > 4055 buildSRPMFromCVS (devel:ruby-amazon-0_9_2-3_fc7): open (ppc2.fedora.redhat.com) -> > > closed > > 0 free 1 open 1 done 0 failed > > 4054 build (dist-fc7, devel:ruby-amazon-0_9_2-3_fc7): open > > (xenbuilder4.fedora.phx.redhat.com) -> FAILED: BuildError: package ruby-amazon not in list > > for tag dist-fc7 > > 0 free 0 open 1 done 1 failed > > make: *** [koji] ??? 1 > > ------------------------------------------------------- > > ("???" means "error") > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4054 > > > > There seem to be several similar packages which failed to build > > (not my packages) > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4007 > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4003 > > > > Help?? > Simple answer: Warren seems to have accidentally not added the latest > batch of CVS additions to Koji. > > I've poked him and the guys in #fedora-admin on IRC to take a look. There's a new step in the cvsadmin process that some of the admins are still getting used to. Thanks for your patience while we re-train our fingers :) josh From jwboyer at jdub.homelinux.org Mon May 7 12:07:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 07:07:36 -0500 Subject: Merge Status - Building available In-Reply-To: <200705052337.56897.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> Message-ID: <1178539656.2990.11.camel@zod.rchland.ibm.com> On Sat, 2007-05-05 at 23:37 +0300, Ville Skytt? wrote: > On Friday 04 May 2007, Josh Boyer wrote: > > On Fri, 2007-05-04 at 22:33 +0900, Mamoru Tasaka wrote: > > > Jesse Keating wrote, at 05/04/2007 03:15 AM +9:00: > > > > Koji will take your build and run with it, you'll see some output on > > > > the CLI. Your build, if successful, will be tagged with 'dist-fc7'. > > > > This is not enough to get it into rawhide, as F7 is in continual slush > > > > freeze. If you need your build to get into rawhide and thus Fedora 7, > > > > you need to follow the policy > > > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > > here. > > Hm. So let's say I update and build an ex-Extras package in the devel branch. > I don't contact rel-eng so it won't get into Rawhide nor F7 per the above. > The question is where _will_ it end up in this scenario? The dist-fc7 tag. Which will be inherited from dist-fc8 (rawhide) once that is created. > > > > A. Does this mean that many packages which were approved and were > > > rebuilt after koji began to work (then marked as 'dist-fc7') > > > will not be pushed into Fedora 7, > > > while they will be pushed into Fedora _Extras_ 6/5 as before (usually > > > within two days)? (i.e. will this cause the situation that > > > newer packages will appear on FE-5/6, but not on Fedora 7)? > > > > Unless you submit a request to rel-eng, yes. You need to have those > > packages tagged as f7-final if you want them in the release. > > What if I have some packages meeting the A) status above, and I don't care > that deeply whether they're in the F7 release but sure do want them in F7 > repositories as soon as possible after the release; do I need to do > something? Yes, you need to email rel-eng with a request. There is no difference between "f7 release" and "in the f7 repo" in regards to Koji. The f7-final tag encompasses both at this point. (And arguably, there is no difference between "f7 release" and "in the f7 repo" at all given that the repos can be enabled and installed from at any point.) josh From jonathan.underwood at gmail.com Mon May 7 12:22:29 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 13:22:29 +0100 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <1178539365.2990.4.camel@zod.rchland.ibm.com> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> Message-ID: <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> On 07/05/07, Josh Boyer wrote: > On Mon, 2007-05-07 at 12:27 +0100, Jonathan Underwood wrote: > > Dear All, > > > > I have created a draft Packaging Guide for Emacs add-on packages here: > > > > http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns > > > > Any comments or suggestions greatfully received. There are a couple of > > spec file templates included which I hope will be useful. > > > > I'd like to get this added to the packaging notes fairly soon - > > presumably this requires FESCO ratification? > > Actually, it needs to go to the Packaging Committee. Well, I think it's too verbose and specific to be part of the packaging guidelines, which are more general in their nature. The point of this document was to outline "Good Practice" and lower the intertial barrier to building add-on packages for Emacs. So I'm not sure where it's best put, and whether it needs to go via Packaging committee approval or not. There seems to be quite a lot of information gathered under http://fedoraproject.org/wiki/Packaging that isn't easily accessed but seems really useful. Jonathan From tcallawa at redhat.com Mon May 7 12:27:49 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 May 2007 07:27:49 -0500 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> Message-ID: <1178540869.3661.6.camel@localhost.localdomain> On Mon, 2007-05-07 at 13:22 +0100, Jonathan Underwood wrote: > On 07/05/07, Josh Boyer wrote: > > On Mon, 2007-05-07 at 12:27 +0100, Jonathan Underwood wrote: > > > Dear All, > > > > > > I have created a draft Packaging Guide for Emacs add-on packages here: > > > > > > http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns > > > > > > Any comments or suggestions greatfully received. There are a couple of > > > spec file templates included which I hope will be useful. > > > > > > I'd like to get this added to the packaging notes fairly soon - > > > presumably this requires FESCO ratification? > > > > Actually, it needs to go to the Packaging Committee. > > Well, I think it's too verbose and specific to be part of the > packaging guidelines, which are more general in their nature. The > point of this document was to outline "Good Practice" and lower the > intertial barrier to building add-on packages for Emacs. So I'm not > sure where it's best put, and whether it needs to go via Packaging > committee approval or not. > > There seems to be quite a lot of information gathered under > http://fedoraproject.org/wiki/Packaging that isn't easily accessed but > seems really useful. If it is under Packaging/, the FPC needs to sign off on it. ~spot From Axel.Thimm at ATrpms.net Mon May 7 12:28:16 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 May 2007 14:28:16 +0200 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> Message-ID: <20070507122816.GA22000@neu.nirvana> On Mon, May 07, 2007 at 01:22:29PM +0100, Jonathan Underwood wrote: > On 07/05/07, Josh Boyer wrote: > >On Mon, 2007-05-07 at 12:27 +0100, Jonathan Underwood wrote: > >> Dear All, > >> > >> I have created a draft Packaging Guide for Emacs add-on packages here: > >> > >> http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns > >> > >> Any comments or suggestions greatfully received. There are a couple of > >> spec file templates included which I hope will be useful. > >> > >> I'd like to get this added to the packaging notes fairly soon - > >> presumably this requires FESCO ratification? > > > >Actually, it needs to go to the Packaging Committee. > > Well, I think it's too verbose and specific to be part of the > packaging guidelines, which are more general in their nature. The > point of this document was to outline "Good Practice" and lower the > intertial barrier to building add-on packages for Emacs. So I'm not > sure where it's best put, and whether it needs to go via Packaging > committee approval or not. > > There seems to be quite a lot of information gathered under > http://fedoraproject.org/wiki/Packaging that isn't easily accessed but > seems really useful. Anything under /Packaging has been approved by the Packaging Committee. Approving something does not mean it gets embedded into the core guidelines, sometimes there is just a link to a subpackage. And there are quite some very detailed sets of guidelines existing in that way, so there is no problem with verbosity ;) But anyway better discuss this on fedora-packaging. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexl at users.sourceforge.net Mon May 7 12:27:59 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 07 May 2007 05:27:59 -0700 Subject: major change release management for former Extras packages? (was Re: Merge Status - Building available) In-Reply-To: <1178539656.2990.11.camel@zod.rchland.ibm.com> (Josh Boyer's message of "Mon\, 07 May 2007 07\:07\:36 -0500") References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <1178539656.2990.11.camel@zod.rchland.ibm.com> Message-ID: >>>>> "JB" == Josh Boyer writes: [...] >> What if I have some packages meeting the A) status above, and I >> don't care that deeply whether they're in the F7 release but sure >> do want them in F7 repositories as soon as possible after the >> release; do I need to do something? JB> Yes, you need to email rel-eng with a request. There is no JB> difference between "f7 release" and "in the f7 repo" in regards to JB> Koji. The f7-final tag encompasses both at this point. JB> (And arguably, there is no difference between "f7 release" and "in JB> the f7 repo" at all given that the repos can be enabled and JB> installed from at any point.) So this seems to imply that all updates to (formerly-Extras) packages for F7 (either before or after the release) must go through rel-eng? If so, this is going to introduce a new bottleneck that hasn't existed up to this point for Extras packages, currently we just build and they're released in the next push. For the point of view out non-Red Hat contributors, it's a major change in the way packages are managed. I can't find any FAQ on the wiki (or definitive discussions on this mailing list) where policy has been established and about how this is supposed to work (other than perhaps mentioning it in discussions in FESCo meetings). This is something needs to be front and centre right now before F7 goes live. Alex From jwboyer at jdub.homelinux.org Mon May 7 12:39:41 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 07:39:41 -0500 Subject: major change release management for former Extras packages? (was Re: Merge Status - Building available) In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <1178539656.2990.11.camel@zod.rchland.ibm.com> Message-ID: <1178541581.2990.19.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 05:27 -0700, Alex Lancaster wrote: > >>>>> "JB" == Josh Boyer writes: > > [...] > > >> What if I have some packages meeting the A) status above, and I > >> don't care that deeply whether they're in the F7 release but sure > >> do want them in F7 repositories as soon as possible after the > >> release; do I need to do something? > > JB> Yes, you need to email rel-eng with a request. There is no > JB> difference between "f7 release" and "in the f7 repo" in regards to > JB> Koji. The f7-final tag encompasses both at this point. > > JB> (And arguably, there is no difference between "f7 release" and "in > JB> the f7 repo" at all given that the repos can be enabled and > JB> installed from at any point.) > > So this seems to imply that all updates to (formerly-Extras) packages > for F7 (either before or after the release) must go through rel-eng? > > If so, this is going to introduce a new bottleneck that hasn't existed > up to this point for Extras packages, currently we just build and > they're released in the next push. For the point of view out non-Red > Hat contributors, it's a major change in the way packages are managed. > > I can't find any FAQ on the wiki (or definitive discussions on this > mailing list) where policy has been established and about how this is > supposed to work (other than perhaps mentioning it in discussions in > FESCo meetings). This is something needs to be front and centre right > now before F7 goes live. We've been pointing people to this page: http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy for a while now... Then there's this: https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00068.html Which also says you need to email rel-eng to get stuff into the f7-final tag. Likely the reason Extras stuff isn't highlighted is because there is no Extras in the merged world. All packages follow the same process. josh From Axel.Thimm at ATrpms.net Mon May 7 12:46:09 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 May 2007 14:46:09 +0200 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <20070507122816.GA22000@neu.nirvana> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> <20070507122816.GA22000@neu.nirvana> Message-ID: <20070507124609.GA23832@neu.nirvana> On Mon, May 07, 2007 at 02:28:16PM +0200, Axel Thimm wrote: > On Mon, May 07, 2007 at 01:22:29PM +0100, Jonathan Underwood wrote: > > On 07/05/07, Josh Boyer wrote: > > >On Mon, 2007-05-07 at 12:27 +0100, Jonathan Underwood wrote: > > >> Dear All, > > >> > > >> I have created a draft Packaging Guide for Emacs add-on packages here: > > >> > > >> http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns > > >> > > >> Any comments or suggestions greatfully received. There are a couple of > > >> spec file templates included which I hope will be useful. > > >> > > >> I'd like to get this added to the packaging notes fairly soon - > > >> presumably this requires FESCO ratification? > > > > > >Actually, it needs to go to the Packaging Committee. > > > > Well, I think it's too verbose and specific to be part of the > > packaging guidelines, which are more general in their nature. The > > point of this document was to outline "Good Practice" and lower the > > intertial barrier to building add-on packages for Emacs. So I'm not > > sure where it's best put, and whether it needs to go via Packaging > > committee approval or not. > > > > There seems to be quite a lot of information gathered under > > http://fedoraproject.org/wiki/Packaging that isn't easily accessed but > > seems really useful. > > Anything under /Packaging has been approved by the Packaging > Committee. Approving something does not mean it gets embedded into the > core guidelines, sometimes there is just a link to a subpackage. s/subpackage/subpage/ > And there are quite some very detailed sets of guidelines existing > in that way, so there is no problem with verbosity ;) > > But anyway better discuss this on fedora-packaging. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Mon May 7 12:50:12 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 13:50:12 +0100 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <20070507122816.GA22000@neu.nirvana> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> <20070507122816.GA22000@neu.nirvana> Message-ID: <645d17210705070550m6aef8888l6e510c42673b84e7@mail.gmail.com> On 07/05/07, Axel Thimm wrote: > But anyway better discuss this on fedora-packaging. OK, thanks, will take the discussion over there. /me groans as he joins yet another mailing list. From alexl at users.sourceforge.net Mon May 7 13:12:46 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 07 May 2007 06:12:46 -0700 Subject: major change release management for former Extras packages? In-Reply-To: <1178541581.2990.19.camel@zod.rchland.ibm.com> (Josh Boyer's message of "Mon\, 07 May 2007 07\:39\:41 -0500") References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <1178539656.2990.11.camel@zod.rchland.ibm.com> <1178541581.2990.19.camel@zod.rchland.ibm.com> Message-ID: >>>>> "JB" == Josh Boyer writes: [...] >> I can't find any FAQ on the wiki (or definitive discussions on this >> mailing list) where policy has been established and about how this >> is supposed to work (other than perhaps mentioning it in >> discussions in FESCo meetings). This is something needs to be >> front and centre right now before F7 goes live. JB> We've been pointing people to this page: JB> http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy JB> for a while now... JB> Then there's this: JB> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00068.html JB> Which also says you need to email rel-eng to get stuff into the JB> f7-final tag. Likely the reason Extras stuff isn't highlighted is JB> because there is no Extras in the merged world. All packages JB> follow the same process. I'm sorry, I don't think it's nearly obvious enough for most non-RH packagers (as the questions in this thread make clear). For example there is no link to that page on http://fedoraproject.org/wiki/PackageMaintainers http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess There should be a message on this list (and maybe fedora-devel-list) spelling out (or linking to a wiki package) exactly what the new procedures are and what they mean for all (former Extras) packagers. I have been monitoring fedora-maintainers as required in the sponsorship/signup for all contributors/packagers and I have yet to see an e-mail with title of something like "Attention all former Extras packages: here is the new release process" So many things are currently not specified, e.g.: 1) What exactly are "tags", "tasks" and "builds" in the new koji build system? How do they relate to each other? What does it mean for tags to "inherit" from each other (I sort of figured out some of this stuff by hunting around on the koji site, but that shouldn't be necessary). 2) Who decides and/or approves rel-eng requests? How long will they take to process? What criteria do they use? Much of this is probably obvious to those inside or closely associated with Red Hat and who are constantly on IRC or following threads in fedora-devel-list, fedora-packaging (in addition to fedora-maintainers) because your used to the rel-eng system because it's been used with Core. To the outside packager/contributor who isn't being paid to monitor all this traffic, however, all this tacit knowledge needs to be made *much* more explicit because it's a world of difference to how Extras has worked up until now and I'm sure I'm not the only one who is somewhat confused by the new processes. Alex From jkeating at redhat.com Mon May 7 13:15:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 06:15:19 -0700 Subject: major change release management for former Extras packages? In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <1178541581.2990.19.camel@zod.rchland.ibm.com> Message-ID: <200705070615.22984.jkeating@redhat.com> On Monday 07 May 2007 06:12:46 Alex Lancaster wrote: > So many things are currently not specified, e.g.: > > 1) What exactly are "tags", "tasks" and "builds" in the new koji build > ? ?system? ?How do they relate to each other? ?What does it mean for > ? ?tags to "inherit" from each other (I sort of figured out some of > ? ?this stuff by hunting around on the koji site, but that shouldn't > ? ?be necessary). > > 2) Who decides and/or approves rel-eng requests? ?How long will they > ? ?take to process? ?What criteria do they use? > > Much of this is probably obvious to those inside or closely associated > with Red Hat and who are constantly on IRC or following threads in > fedora-devel-list, fedora-packaging (in addition to > fedora-maintainers) because your used to the rel-eng system because > it's been used with Core. > > To the outside packager/contributor who isn't being paid to monitor > all this traffic, however, all this tacit knowledge needs to be made > *much* more explicit because it's a world of difference to how Extras > has worked up until now and I'm sure I'm not the only one who is > somewhat confused by the new processes. These things are not posted as we're not done merging yet. Please have some patience. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon May 7 13:28:42 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 08:28:42 -0500 Subject: major change release management for former Extras packages? In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463B3641.5090406@ioa.s.u-tokyo.ac.jp> <1178285694.3026.166.camel@zod.rchland.ibm.com> <200705052337.56897.ville.skytta@iki.fi> <1178539656.2990.11.camel@zod.rchland.ibm.com> <1178541581.2990.19.camel@zod.rchland.ibm.com> Message-ID: <1178544522.2990.45.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 06:12 -0700, Alex Lancaster wrote: > >>>>> "JB" == Josh Boyer writes: > > [...] > > >> I can't find any FAQ on the wiki (or definitive discussions on this > >> mailing list) where policy has been established and about how this > >> is supposed to work (other than perhaps mentioning it in > >> discussions in FESCo meetings). This is something needs to be > >> front and centre right now before F7 goes live. > > JB> We've been pointing people to this page: > > JB> http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > JB> for a while now... > > JB> Then there's this: > > JB> https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00068.html > > JB> Which also says you need to email rel-eng to get stuff into the > JB> f7-final tag. Likely the reason Extras stuff isn't highlighted is > JB> because there is no Extras in the merged world. All packages > JB> follow the same process. > > I'm sorry, I don't think it's nearly obvious enough for most non-RH > packagers (as the questions in this thread make clear). For example I'm a non-RH packager. Don't generalize based on company, because I can assure you there are RH packagers that don't fully understand what to do either. > there is no link to that page on > > http://fedoraproject.org/wiki/PackageMaintainers > http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess These are out of date now, yes. > > There should be a message on this list (and maybe fedora-devel-list) > spelling out (or linking to a wiki package) exactly what the new > procedures are and what they mean for all (former Extras) packagers. > > I have been monitoring fedora-maintainers as required in the > sponsorship/signup for all contributors/packagers and I have yet to > see an e-mail with title of something like "Attention all former > Extras packages: here is the new release process" Ok, fair enough. And now you've started something to work from. > > So many things are currently not specified, e.g.: > > 1) What exactly are "tags", "tasks" and "builds" in the new koji build > system? How do they relate to each other? What does it mean for > tags to "inherit" from each other (I sort of figured out some of > this stuff by hunting around on the koji site, but that shouldn't > be necessary). Builds should already be known. It doesn't differ from plague. Tasks are "currently on-going job requests to the buildsystem". Those can be multiple types of requests, but typically take the form of builds. Tags are really the only new thing here. And I don't think you really want the definition of a tag, but rather "what do the individual tags mean?" So here's a brief overview: dist-fc7: The is the tag that gets applied to all currently devel builds upon successful completion. If we weren't under freeze, it would mean "rawhide". f7-final: This tag is what represents the state of both rawhide and the current final F7 repository. If you want your package included in F7, then you need to get it tagged with this tag. dist-fc8: This hasn't been created yet, but once it is it will represent rawhide again. Should happen after F7 is branched. > > 2) Who decides and/or approves rel-eng requests? How long will they > take to process? What criteria do they use? The rel-eng folks decide. There's a link on the freeze page to who is actually on rel-eng. As for how long it takes, normally it's within 1 day. The criteria differ based on each request, so it's fairly pointless to try and document them. Usually it's something along the lines of "how many things will this update break if it introduces a bug", etc. > To the outside packager/contributor who isn't being paid to monitor > all this traffic, however, all this tacit knowledge needs to be made > *much* more explicit because it's a world of difference to how Extras > has worked up until now and I'm sure I'm not the only one who is > somewhat confused by the new processes. Fair enough, and we're working on it. josh From coldwell at redhat.com Mon May 7 13:44:01 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Mon, 7 May 2007 09:44:01 -0400 (EDT) Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <645d17210705070550m6aef8888l6e510c42673b84e7@mail.gmail.com> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> <20070507122816.GA22000@neu.nirvana> <645d17210705070550m6aef8888l6e510c42673b84e7@mail.gmail.com> Message-ID: On Mon, 7 May 2007, Jonathan Underwood wrote: > On 07/05/07, Axel Thimm wrote: > > But anyway better discuss this on fedora-packaging. > > OK, thanks, will take the discussion over there. > > /me groans as he joins yet another mailing list. I read the Wiki page and it looks sane to me. I would rather not join yet another mailing list, so if you don't mind, could you shoot me an email with the outcome? Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From alexl at users.sourceforge.net Mon May 7 14:02:02 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 07 May 2007 07:02:02 -0700 Subject: major change release management for former Extras packages? In-Reply-To: <200705070615.22984.jkeating@redhat.com> (Jesse Keating's message of "Mon\, 7 May 2007 06\:15\:19 -0700") References: <200705031416.00604.jkeating@redhat.com> <1178541581.2990.19.camel@zod.rchland.ibm.com> <200705070615.22984.jkeating@redhat.com> Message-ID: <82tzuo91gl.fsf@delpy.biol.berkeley.edu> >>>>> "JK" == Jesse Keating writes: [...] >> To the outside packager/contributor who isn't being paid to monitor >> all this traffic, however, all this tacit knowledge needs to be >> made *much* more explicit because it's a world of difference to how >> Extras has worked up until now and I'm sure I'm not the only one >> who is somewhat confused by the new processes. JK> These things are not posted as we're not done merging yet. Please JK> have some patience. OK, fair enough. I guess I thought that merge was more or less complete now that the build system was back up. ;) My main concern with the new process (at least as described in http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy) is that it could become somewhat of a disincentive for contributors. For example, with Extras <= FC-6 you can simply update the package and build it and it will generally go into the repo in a few days. While I complete understand the need for and approve of a QA process for packages (especially in the merged world), I am concerned that the new extra (sic) step involved in rel-eng not be too onerous. For example, currently there is a steady stream of updates to Extras packages every day, and if even fairly minor changes need to be approved by a committee then I can see the queue rapidly becoming full. In addition having to justify each change (even for "leaf" packages which don't depend on or otherwise affect any other packages) and waiting longer for approval, or disallowing version upgrades (even if they don't break binary compatibility), could potentially discourage contributors because the rapid release cycle of Extras packages (compared to Core) is part of what made being a contributor to Extras appealing in the first place. Of course, this may all be moot if the final policy for updating packages (after F7 is released) differs somewhat from that described in http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy but those are some potential issues I can see with the release process as I currently interpret it. Alex From tcallawa at redhat.com Mon May 7 14:10:41 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 May 2007 09:10:41 -0500 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> <20070507122816.GA22000@neu.nirvana> <645d17210705070550m6aef8888l6e510c42673b84e7@mail.gmail.com> Message-ID: <1178547041.3661.14.camel@localhost.localdomain> On Mon, 2007-05-07 at 09:44 -0400, Chip Coldwell wrote: > On Mon, 7 May 2007, Jonathan Underwood wrote: > > > On 07/05/07, Axel Thimm wrote: > > > But anyway better discuss this on fedora-packaging. > > > > OK, thanks, will take the discussion over there. > > > > /me groans as he joins yet another mailing list. > > I read the Wiki page and it looks sane to me. I would rather not join > yet another mailing list, so if you don't mind, could you shoot me an > email with the outcome? To be fair, you don't have to join fedora-packaging to submit a draft for consideration by the Fedora Packaging Committee. The steps for that are documented here: http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30ac87c30733f0c008b146 Strictly speaking, anything that shows up on DraftsTodo will get on our agenda. We consider Drafts, vote on them, and approved drafts go to FESCo for ratification. When FESCo signs off on them, then we add them to the Packaging/ hierarchy. Last but not least, we announce the committed changes to fedora-maintainers and fedora-devel. We, of course, greatly encourage participation on our low-traffic mailing list. ~spot From tcallawa at redhat.com Mon May 7 14:20:45 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 May 2007 09:20:45 -0500 Subject: [Guidelines Change] Conflicts Message-ID: <1178547645.3661.19.camel@localhost.localdomain> A new document was added to the Packaging/ hierarchy: Conflicts. This document is also linked from the Packaging/Guidelines. For convenience, the contents of the current Packaging/Conflicts policy is presented below: ================ Conflicts Whenever possible, Fedora packages should avoid conflicting with each other. Unfortunately, this is not always possible. These guidelines illustrate how conflicts should be handled in Fedora, specifically concerning when and when not to use the Conflicts: field. Acceptable Uses of Conflicts: As a general rule, Fedora packages must NOT contain any usage of the Conflicts: field. This field is commonly misused, when a Requires: would usually be more appropriate. It confuses depsolvers and end-users for no good reason. However, there are some cases in which using the Conflicts: field is appropriate and acceptable. Implicit Conflicts Keep in mind that implicit conflicts are NEVER acceptable. If your package conflicts with another package, then you must either resolve the conflict, or mark it with Conflicts:. Optional Functionality Some software can utilize other optional software applications if present, but do not require them to be installed. If they are not installed, the software will still function properly. However, if those other "optional applications" are too old, then the software won't work. This is an acceptable use of the Conflicts: field. The packager must document the reason in a comment above the Conflicts: field: Example: # If the unrar utility is present, super-unpacker can open rar files. However, it only works with unrar >= 2.0. Unrar is not required for this app to function. Conflicts: unrar < 2.0 If the software links to the libraries of another package, it must use Requires: instead of Conflicts: to mark that dependency. Also, if the software does not function properly without another package being installed, it must use Requires: instead of Conflicts:. The packager should ask: If the package (at the correct version) in Conflicts: is not present, will my package be functional? If the answer is yes, then it is probably a valid use of Conflicts:. If the answer is no, then it is almost certainly a better case for Requires:. For example, if foo-game needs libbar to run, but will not work with libbar that is older than 1.2.3: WRONG: Conflicts: libbar < 1.2.3 RIGHT: Requires: libbar >= 1.2.3 Packagers should keep usage of Conflicts: to a bare minimum. Only upgrading from two previous release of Fedora is supported, so Conflicts against older packages than that, while technically correct, are unnecessary, and should not be included. Compat Package Conflicts It is acceptable to use Conflicts: in some cases involving compat packages. These are the cases where it is not feasible to patch applications to look in alternate locations for the -compat files, so the foo-devel and foo-compat-devel packages need to Conflict:. Whenever possible, this should be avoided. Conflicting Files There are many types of files which can conflict between multiple packages. Fedora strongly discourages using Conflicts: to resolve these cases. Here are some suggestions which can be used to resolve these conflicts (note that not all file conflict cases are listed, nor are all possible solutions): Man Page Name Conflicts * Rename the man pages to slightly alter the suffix of the man page (e.g man1/check.1.gz and man1/check.1foo.gz) * Rename the man pages to include a prefix of the providing package (e.g. foo-check.1.gz and bar-check.1.gz) Library Name Conflicts * Put the library in a subdirectory of /usr/lib or /lib and include a ld.so.conf file in /etc/ld.so.conf.d/. Header Name Conflicts * Put the headers in a subdirectory of /usr/include. Binary Name Conflicts * Convince upstream to rename the binaries to something less generic (or just less conflicting). * In the case where the conflicting binaries provide the same functionality, you can then rename the binaries with a prefix, and use "alternatives" to let the end user to select which generic name is the default. Note that this is usually not the case. Other Uses of Conflicts: If you find yourself in a situation where you feel that your package has to conflict with another package (either explicitly or implicitly), but does not fit the documented accepted cases above, then you need to make your case to the Fedora Packaging Committee. If they agree, then, and only then can you use Conflicts: in a Fedora package. Remember, whenever you use Conflicts:, you are also required to include the reasoning in a comment next to the Conflicts: entry, so that it will be abundantly clear why it needed to exist. ~spot From jkeating at redhat.com Mon May 7 14:32:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 10:32:05 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <82tzuo91gl.fsf@delpy.biol.berkeley.edu> References: <200705031416.00604.jkeating@redhat.com> <200705070615.22984.jkeating@redhat.com> <82tzuo91gl.fsf@delpy.biol.berkeley.edu> Message-ID: <200705071032.08991.jkeating@redhat.com> On Monday 07 May 2007 10:02:02 Alex Lancaster wrote: > For example, with Extras <= FC-6 you can simply update the package and > build it and it will generally go into the repo in a few days. ?While > I complete understand the need for and approve of a QA process for > packages (especially in the merged world), I am concerned that the new > extra (sic) step involved in rel-eng not be too onerous. > > For example, currently there is a steady stream of updates to Extras > packages every day, and if even fairly minor changes need to be > approved by a committee then I can see the queue rapidly becoming > full. ?In addition having to justify each change (even for "leaf" > packages which don't depend on or otherwise affect any other packages) > and waiting longer for approval, or disallowing version upgrades (even > if they don't break binary compatibility), could potentially > discourage contributors because the rapid release cycle of Extras > packages (compared to Core) is part of what made being a contributor > to Extras appealing in the first place. > > Of course, this may all be moot if the final policy for updating > packages (after F7 is released) differs somewhat from that described > in http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > but those are some potential issues I can see with the release process > as I currently interpret it. It is different. That's why it's a DevelFreezePolicy. For updates to a released platform, we ask that you follow some simple guides like avoid soname bumping that would cause N* number of rebuilds of "downstream" packages and the like. There will be a tool to use, bodhi, to request your update and fill in information about why this update is being issued, and there will still need to be somebody to do the depchecking/signing/pushing of the update set. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Mon May 7 15:00:09 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 May 2007 17:00:09 +0200 Subject: major change release management for former Extras packages? In-Reply-To: <200705071032.08991.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705070615.22984.jkeating@redhat.com> <82tzuo91gl.fsf@delpy.biol.berkeley.edu> <200705071032.08991.jkeating@redhat.com> Message-ID: <20070507150008.GB24228@ryvius.pekin.waw.pl> On Monday, 07 May 2007 at 16:32, Jesse Keating wrote: > On Monday 07 May 2007 10:02:02 Alex Lancaster wrote: > > For example, with Extras <= FC-6 you can simply update the package and > > build it and it will generally go into the repo in a few days. ?While > > I complete understand the need for and approve of a QA process for > > packages (especially in the merged world), I am concerned that the new > > extra (sic) step involved in rel-eng not be too onerous. > > > > For example, currently there is a steady stream of updates to Extras > > packages every day, and if even fairly minor changes need to be > > approved by a committee then I can see the queue rapidly becoming > > full. ?In addition having to justify each change (even for "leaf" > > packages which don't depend on or otherwise affect any other packages) > > and waiting longer for approval, or disallowing version upgrades (even > > if they don't break binary compatibility), could potentially > > discourage contributors because the rapid release cycle of Extras > > packages (compared to Core) is part of what made being a contributor > > to Extras appealing in the first place. > > > > Of course, this may all be moot if the final policy for updating > > packages (after F7 is released) differs somewhat from that described > > in http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > but those are some potential issues I can see with the release process > > as I currently interpret it. > > It is different. That's why it's a DevelFreezePolicy. For updates to a > released platform, we ask that you follow some simple guides like avoid > soname bumping that would cause N* number of rebuilds of "downstream" > packages and the like. There will be a tool to use, bodhi, to request your > update and fill in information about why this update is being issued, and > there will still need to be somebody to do the depchecking/signing/pushing of > the update set. OK, fair enough, though I don't like jumping through more hoops than I used to. One more question (I may have missed the answer in this thread): What happens if I update a package and tag and build it *now*. Will it end up in rawhide or not? Will it end up in post-release repo or not? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From fedora at leemhuis.info Mon May 7 15:06:29 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 May 2007 17:06:29 +0200 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178547645.3661.19.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> Message-ID: <463F4075.9050001@leemhuis.info> Tom "spot" Callaway schrieb: > A new document was added to the Packaging/ hierarchy: Conflicts. > This document is also linked from the Packaging/Guidelines. I'd like to thank all members of the packaging committee for their work and this policy. > [...] > Implicit Conflicts > Keep in mind that implicit conflicts are NEVER acceptable. If your > package conflicts with another package, then you must either resolve the > conflict, or mark it with Conflicts:. /me hopes we sooner or later have a script running somewhere on a server regularly that checks for implicit conflicts and bugs people if it finds any > [...] > Other Uses of Conflicts: > If you find yourself in a situation where you feel that your package has > to conflict with another package (either explicitly or implicitly), but > does not fit the documented accepted cases above, then you need to make > your case to the Fedora Packaging Committee. If they agree, then, and > only then can you use Conflicts: in a Fedora package. [...] Just wondering (and *not* meant as a critique!): Wasn't the "unwritten rule" that the Packaging Committee handles theoretical packaging while FESCo handles practical packaging? Or did I get something wrong? *If* the Packaging Committee handles practical packaging like "Approve Conflicts" I'd suggest we should consider moving "Request for packages with static libs" and maybe "Appoval requests for kmod packages" from FESCo's duty's over to the Packaging Committee. CU thl From jwboyer at jdub.homelinux.org Mon May 7 15:01:14 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 10:01:14 -0500 Subject: major change release management for former Extras packages? In-Reply-To: <20070507150008.GB24228@ryvius.pekin.waw.pl> References: <200705031416.00604.jkeating@redhat.com> <200705070615.22984.jkeating@redhat.com> <82tzuo91gl.fsf@delpy.biol.berkeley.edu> <200705071032.08991.jkeating@redhat.com> <20070507150008.GB24228@ryvius.pekin.waw.pl> Message-ID: <1178550074.2990.71.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 17:00 +0200, Dominik 'Rathann' Mierzejewski wrote: > OK, fair enough, though I don't like jumping through more hoops than I used > to. One more question (I may have missed the answer in this thread): What > happens if I update a package and tag and build it *now*. Will it end up in > rawhide or not? Will it end up in post-release repo or not? No, it won't. Right *now*, to get it into rawhide (and the release repo), you need to email rel-eng with a request. After F7 has been branched, rawhide will be opened up again and you shouldn't have to do that any longer. josh From fedora at leemhuis.info Mon May 7 15:12:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 May 2007 17:12:30 +0200 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178547645.3661.19.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> Message-ID: <463F41DE.6060508@leemhuis.info> (sending this again; this time with proper cross-posting) Tom "spot" Callaway schrieb: > A new document was added to the Packaging/ hierarchy: Conflicts. > This document is also linked from the Packaging/Guidelines. I'd like to thank all members of the packaging committee for their work and this policy. > [...] > Implicit Conflicts > Keep in mind that implicit conflicts are NEVER acceptable. If your > package conflicts with another package, then you must either resolve the > conflict, or mark it with Conflicts:. /me hopes we sooner or later have a script running somewhere on a server regularly that checks for implicit conflicts and bugs people if it finds any > [...] > Other Uses of Conflicts: > If you find yourself in a situation where you feel that your package has > to conflict with another package (either explicitly or implicitly), but > does not fit the documented accepted cases above, then you need to make > your case to the Fedora Packaging Committee. If they agree, then, and > only then can you use Conflicts: in a Fedora package. [...] Just wondering (and *not* meant as a critique!): Wasn't the "unwritten rule" that the Packaging Committee handles theoretical packaging while FESCo handles practical packaging? Or did I get something wrong? *If* the Packaging Committee handles practical packaging like "Approve Conflicts" I'd suggest we should consider moving "Request for packages with static libs" and maybe "Appoval requests for kmod packages" from FESCo's duty's over to the Packaging Committee. CU thl From tcallawa at redhat.com Mon May 7 15:14:51 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 May 2007 10:14:51 -0500 Subject: [Guidelines Change] Conflicts In-Reply-To: <463F4075.9050001@leemhuis.info> References: <1178547645.3661.19.camel@localhost.localdomain> <463F4075.9050001@leemhuis.info> Message-ID: <1178550891.3661.22.camel@localhost.localdomain> On Mon, 2007-05-07 at 17:06 +0200, Thorsten Leemhuis wrote: > Just wondering (and *not* meant as a critique!): Wasn't the "unwritten > rule" that the Packaging Committee handles theoretical packaging while > FESCo handles practical packaging? Or did I get something wrong? > > *If* the Packaging Committee handles practical packaging like "Approve > Conflicts" I'd suggest we should consider moving "Request for packages > with static libs" and maybe "Appoval requests for kmod packages" from > FESCo's duty's over to the Packaging Committee. Not quite sure. Does FESCo want to handle "practical packaging" or push it to the FPC? ~spot From jwboyer at jdub.homelinux.org Mon May 7 15:13:18 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 10:13:18 -0500 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178550891.3661.22.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> <463F4075.9050001@leemhuis.info> <1178550891.3661.22.camel@localhost.localdomain> Message-ID: <1178550798.2990.76.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 10:14 -0500, Tom "spot" Callaway wrote: > On Mon, 2007-05-07 at 17:06 +0200, Thorsten Leemhuis wrote: > > > Just wondering (and *not* meant as a critique!): Wasn't the "unwritten > > rule" that the Packaging Committee handles theoretical packaging while > > FESCo handles practical packaging? Or did I get something wrong? > > > > *If* the Packaging Committee handles practical packaging like "Approve > > Conflicts" I'd suggest we should consider moving "Request for packages > > with static libs" and maybe "Appoval requests for kmod packages" from > > FESCo's duty's over to the Packaging Committee. > > Not quite sure. Does FESCo want to handle "practical packaging" or push > it to the FPC? Personally, I'd rather leave it to FESCo. Especially for kmods and static libs. Though I will guarantee you that for things like Conflicts, etc the Packaging Committee's opinion will be very welcome ;) josh From jkeating at redhat.com Mon May 7 15:22:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 11:22:10 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <20070507150008.GB24228@ryvius.pekin.waw.pl> References: <200705031416.00604.jkeating@redhat.com> <200705071032.08991.jkeating@redhat.com> <20070507150008.GB24228@ryvius.pekin.waw.pl> Message-ID: <200705071122.10507.jkeating@redhat.com> On Monday 07 May 2007 11:00:09 Dominik 'Rathann' Mierzejewski wrote: > OK, fair enough, though I don't like jumping through more hoops than I used > to. You may not, but users are pretty tired of seeing 40+ package updates available and not having a single clue about _why_ those packages are available for update. And making sure that repos don't have broken deps is rather important. Marking security updates as such is _very_ important. This really is more for the user than for the engineers. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Mon May 7 15:47:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 07 May 2007 17:47:39 +0200 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178550798.2990.76.camel@zod.rchland.ibm.com> References: <1178547645.3661.19.camel@localhost.localdomain> <463F4075.9050001@leemhuis.info> <1178550891.3661.22.camel@localhost.localdomain> <1178550798.2990.76.camel@zod.rchland.ibm.com> Message-ID: <463F4A1B.9060505@leemhuis.info> Josh Boyer schrieb: > On Mon, 2007-05-07 at 10:14 -0500, Tom "spot" Callaway wrote: >> On Mon, 2007-05-07 at 17:06 +0200, Thorsten Leemhuis wrote: >>> Just wondering (and *not* meant as a critique!): Wasn't the "unwritten >>> rule" that the Packaging Committee handles theoretical packaging while >>> FESCo handles practical packaging? Or did I get something wrong? >>> *If* the Packaging Committee handles practical packaging like "Approve >>> Conflicts" I'd suggest we should consider moving "Request for packages >>> with static libs" and maybe "Appoval requests for kmod packages" from >>> FESCo's duty's over to the Packaging Committee. >> Not quite sure. Does FESCo want to handle "practical packaging" or push >> it to the FPC? > Personally, I'd rather leave it to FESCo. +1, but I don't really care -- but I'd prefer if responsibilities are clearly differentiated in areas. IOW: one group should handle kmods, static libs and conflicts. CU thl From jonathan.underwood at gmail.com Mon May 7 16:11:07 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 17:11:07 +0100 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> <20070507122816.GA22000@neu.nirvana> <645d17210705070550m6aef8888l6e510c42673b84e7@mail.gmail.com> Message-ID: <645d17210705070911y490d086dtcef7005550d556d7@mail.gmail.com> On 07/05/07, Chip Coldwell wrote: > I read the Wiki page and it looks sane to me. I would rather not join > yet another mailing list, so if you don't mind, could you shoot me an > email with the outcome? Thanks for looking over the draft, Chip. I've sent an email to the packaging list, and I'll let you know off-list the eventual outcome. Best wishes, Jonathan. From jonathan.underwood at gmail.com Mon May 7 16:12:07 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 May 2007 17:12:07 +0100 Subject: Packaging Draft for Emacs add-on packages In-Reply-To: <1178547041.3661.14.camel@localhost.localdomain> References: <645d17210705070427mb20508dk2a086b79fbf28216@mail.gmail.com> <1178539365.2990.4.camel@zod.rchland.ibm.com> <645d17210705070522u373f389aw8c6ed472ee51c5d9@mail.gmail.com> <20070507122816.GA22000@neu.nirvana> <645d17210705070550m6aef8888l6e510c42673b84e7@mail.gmail.com> <1178547041.3661.14.camel@localhost.localdomain> Message-ID: <645d17210705070912u3efebe35va7d7e288163c742e@mail.gmail.com> On 07/05/07, Tom spot Callaway wrote: > To be fair, you don't have to join fedora-packaging to submit a draft > for consideration by the Fedora Packaging Committee. > > The steps for that are documented here: > > http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30ac87c30733f0c008b146 > > Strictly speaking, anything that shows up on DraftsTodo will get on our > agenda. We consider Drafts, vote on them, and approved drafts go to > FESCo for ratification. When FESCo signs off on them, then we add them > to the Packaging/ hierarchy. Last but not least, we announce the > committed changes to fedora-maintainers and fedora-devel. Thanks for the clarification and pointer to the relevant page. From jdennis at redhat.com Mon May 7 17:07:36 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 07 May 2007 13:07:36 -0400 Subject: confused by f7 vs. f7-final, what koji package shows, and ?tagID Message-ID: <1178557656.26445.68.camel@finch.boston.redhat.com> I must be thick :-) But I can't figure out if the correct version of a package is in f7 final. First of all, what is the difference between the f7 and f7-final? % koji latest-pkg f7-final shows an entirely different package NVR than the what appears to have been built into f7 (a.k.a devel with an f7 disttag) > The list of package > builds included in the f7-final tag can be viewed via: > http://koji.fedoraproject.org/koji/packages?tagID=10 A few questions here: First, is there some way to query f7-final packages other than magically knowing to use tagID=10 Entering that URL brings up a list of f7-final packages, but it does not list the NVR of the package, there is however a link to click for the package, so follow that link, all you get is a list of builds with no correlation to which NVR is in the "release". How does one determine what NVR is in f7? I assume if "koji latest-pkg f7-final " does not return the expected NVR or a current NVR as shown in the package build list we need to email releng asking it to be included? -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From dominik at greysector.net Mon May 7 17:13:57 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 May 2007 19:13:57 +0200 Subject: major change release management for former Extras packages? In-Reply-To: <1178550074.2990.71.camel@zod.rchland.ibm.com> References: <200705031416.00604.jkeating@redhat.com> <200705070615.22984.jkeating@redhat.com> <82tzuo91gl.fsf@delpy.biol.berkeley.edu> <200705071032.08991.jkeating@redhat.com> <20070507150008.GB24228@ryvius.pekin.waw.pl> <1178550074.2990.71.camel@zod.rchland.ibm.com> Message-ID: <20070507171357.GB26384@ryvius.pekin.waw.pl> On Monday, 07 May 2007 at 17:01, Josh Boyer wrote: > On Mon, 2007-05-07 at 17:00 +0200, Dominik 'Rathann' Mierzejewski wrote: > > OK, fair enough, though I don't like jumping through more hoops than I used > > to. One more question (I may have missed the answer in this thread): What > > happens if I update a package and tag and build it *now*. Will it end up in > > rawhide or not? Will it end up in post-release repo or not? > > No, it won't. Right *now*, to get it into rawhide (and the release > repo), you need to email rel-eng with a request. So... all my unpushed updates would actually be reverted when rawhide is open again? That's... unexpected and ill-conceived, to say the least. Actually it stiffles development at this point. It means I can't happily hack away even if I'm sure my currently published package set is stable. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jwboyer at jdub.homelinux.org Mon May 7 17:15:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 12:15:22 -0500 Subject: major change release management for former Extras packages? In-Reply-To: <20070507171357.GB26384@ryvius.pekin.waw.pl> References: <200705031416.00604.jkeating@redhat.com> <200705070615.22984.jkeating@redhat.com> <82tzuo91gl.fsf@delpy.biol.berkeley.edu> <200705071032.08991.jkeating@redhat.com> <20070507150008.GB24228@ryvius.pekin.waw.pl> <1178550074.2990.71.camel@zod.rchland.ibm.com> <20070507171357.GB26384@ryvius.pekin.waw.pl> Message-ID: <1178558122.2990.93.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 19:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 07 May 2007 at 17:01, Josh Boyer wrote: > > On Mon, 2007-05-07 at 17:00 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > OK, fair enough, though I don't like jumping through more hoops than I used > > > to. One more question (I may have missed the answer in this thread): What > > > happens if I update a package and tag and build it *now*. Will it end up in > > > rawhide or not? Will it end up in post-release repo or not? > > > > No, it won't. Right *now*, to get it into rawhide (and the release > > repo), you need to email rel-eng with a request. > > So... all my unpushed updates would actually be reverted when rawhide is > open again? NO. All of your unpushed packages are getting tagged with dist-fc7. dist-fc8 will inherit all of those packages. Rawhide will be dist-fc8 after F7 is branched. You asked about getting packages into rawhide *now*. Right *now*, rawhide == f7-final. After F7 is branched, it will be dist-fc8, which will inherit everything from dist-fc7. Which _includes_ all the builds that have been tagged with that. josh From jkeating at redhat.com Mon May 7 17:22:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 13:22:39 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <20070507171357.GB26384@ryvius.pekin.waw.pl> References: <200705031416.00604.jkeating@redhat.com> <1178550074.2990.71.camel@zod.rchland.ibm.com> <20070507171357.GB26384@ryvius.pekin.waw.pl> Message-ID: <200705071322.39922.jkeating@redhat.com> On Monday 07 May 2007 13:13:57 Dominik 'Rathann' Mierzejewski wrote: > So... all my unpushed updates would actually be reverted when rawhide is > open again? > > That's... unexpected and ill-conceived, to say the least. Actually it > stiffles development at this point. It means I can't happily hack away > even if I'm sure my currently published package set is stable. Incorrect. dist-fc8 or dist-f8 or whatever we call it will inherit from dist-fc7, and thus any unpublished builds will magically show up. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Mon May 7 17:24:22 2007 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 07 May 2007 13:24:22 -0400 Subject: confused by f7 vs. f7-final, what koji package shows, and ?tagID In-Reply-To: <1178557656.26445.68.camel@finch.boston.redhat.com> References: <1178557656.26445.68.camel@finch.boston.redhat.com> Message-ID: <463F60C6.7050201@redhat.com> John Dennis wrote: > I must be thick :-) But I can't figure out if the correct version of a > package is in f7 final. > > First of all, what is the difference between the f7 and f7-final? > > % koji latest-pkg f7-final If we were to release FC7 today, this would be the version number you'd get. > > shows an entirely different package NVR than the what appears to have > been built into f7 (a.k.a devel with an f7 disttag) Correct. koji latest-pkg dist-fc7 is the latest built version. You need to request this moved to f7-final if you want it included in FC7. See http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > How does one determine what NVR is in f7? koji latest-pkg f7-final > > I assume if "koji latest-pkg f7-final " does not return the > expected NVR or a current NVR as shown in the package build list we need > to email releng asking it to be included? Yes. From jdennis at redhat.com Mon May 7 17:28:54 2007 From: jdennis at redhat.com (John Dennis) Date: Mon, 07 May 2007 13:28:54 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <1178558122.2990.93.camel@zod.rchland.ibm.com> References: <200705031416.00604.jkeating@redhat.com> <200705070615.22984.jkeating@redhat.com> <82tzuo91gl.fsf@delpy.biol.berkeley.edu> <200705071032.08991.jkeating@redhat.com> <20070507150008.GB24228@ryvius.pekin.waw.pl> <1178550074.2990.71.camel@zod.rchland.ibm.com> <20070507171357.GB26384@ryvius.pekin.waw.pl> <1178558122.2990.93.camel@zod.rchland.ibm.com> Message-ID: <1178558934.26445.72.camel@finch.boston.redhat.com> On Mon, 2007-05-07 at 12:15 -0500, Josh Boyer wrote: > Right *now*, rawhide == f7-final. Really? Are you saying this in a "non-specific generic hand waving manner" or do you really mean the NVR in devel is the NVR in f7-final? -- John Dennis Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 From jkeating at redhat.com Mon May 7 17:37:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 13:37:28 -0400 Subject: confused by f7 vs. f7-final, what koji package shows, and ?tagID In-Reply-To: <1178557656.26445.68.camel@finch.boston.redhat.com> References: <1178557656.26445.68.camel@finch.boston.redhat.com> Message-ID: <200705071337.28885.jkeating@redhat.com> On Monday 07 May 2007 13:07:36 John Dennis wrote: > I must be thick :-) But I can't figure out if the correct version of a > package is in f7 final. > > First of all, what is the difference between the f7 and f7-final? f7 doesn't exist as a tag. There is 'dist-fc7' and 'f7-final' > % koji latest-pkg f7-final > > shows an entirely different package NVR than the what appears to have > been built into f7 (a.k.a devel with an f7 disttag) Correct. f7-final is the freeze tag that we are using to track the accepted packages for Fedora 7. This is the final freeze period. > > The list of package > > builds included in the f7-final tag can be viewed via: > > > > http://koji.fedoraproject.org/koji/packages?tagID=10 > > A few questions here: > > First, is there some way to query f7-final packages other than magically > knowing to use tagID=10 koji latest-pkg f7-final koji list-tagged f7-final browse to tags in koji web, click on f7-final etc... > Entering that URL brings up a list of f7-final packages, but it does not > list the NVR of the package, there is however a link to click for the > package, so follow that link, all you get is a list of builds with no > correlation to which NVR is in the "release". THat URL is probably the wrong URL, where did you see it again? Anywhere other than the mail you replied to? http://koji.fedoraproject.org/koji/builds?tagID=10 is a better url as it shows the builds. > How does one determine what NVR is in f7? See above options. > I assume if "koji latest-pkg f7-final " does not return the > expected NVR or a current NVR as shown in the package build list we need > to email releng asking it to be included? Yes. Builds done from devel/ get tagged with dist-fc7, which isn't enough. They need to be tagged with f7-final which requires rel-eng interaction, as stated in http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy For a more global look at what we do, see http://fedoraproject.org/wiki/ReleaseEngineering/Overview -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon May 7 17:37:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 12:37:35 -0500 Subject: major change release management for former Extras packages? In-Reply-To: <1178558934.26445.72.camel@finch.boston.redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705070615.22984.jkeating@redhat.com> <82tzuo91gl.fsf@delpy.biol.berkeley.edu> <200705071032.08991.jkeating@redhat.com> <20070507150008.GB24228@ryvius.pekin.waw.pl> <1178550074.2990.71.camel@zod.rchland.ibm.com> <20070507171357.GB26384@ryvius.pekin.waw.pl> <1178558122.2990.93.camel@zod.rchland.ibm.com> <1178558934.26445.72.camel@finch.boston.redhat.com> Message-ID: <1178559455.2990.99.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 13:28 -0400, John Dennis wrote: > On Mon, 2007-05-07 at 12:15 -0500, Josh Boyer wrote: > > Right *now*, rawhide == f7-final. > > Really? Are you saying this in a "non-specific generic hand waving > manner" or do you really mean the NVR in devel is the NVR in f7-final? No. f7-final is a tag. Rawhide itself (which hasn't actually existed in a koji based world yet) is comprised of packages that are tagged as f7-final. If there is a package that has been built but not tagged with f7-final, it's not in rawhide. So the state of devel in CVS is not reflective of either rawhide or the final release at the moment. It all depends on what NVR is tagged with f7-final. josh From jkeating at redhat.com Mon May 7 17:45:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 13:45:03 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <1178558934.26445.72.camel@finch.boston.redhat.com> References: <200705031416.00604.jkeating@redhat.com> <1178558122.2990.93.camel@zod.rchland.ibm.com> <1178558934.26445.72.camel@finch.boston.redhat.com> Message-ID: <200705071345.03281.jkeating@redhat.com> On Monday 07 May 2007 13:28:54 John Dennis wrote: > Really? Are you saying this in a "non-specific generic hand waving > manner" or do you really mean the NVR in devel is the NVR in f7-final? I don't even know how to answer this question. "Rawhide" what we call the development/ tree we (used to, and hope to again soon) publish each night is composed from the packages tagged with f7-final. The isos and trees we spin for the release of Fedora 7 will also come from this tag. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon May 7 17:56:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 13:56:25 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <1178559455.2990.99.camel@zod.rchland.ibm.com> References: <200705031416.00604.jkeating@redhat.com> <1178558934.26445.72.camel@finch.boston.redhat.com> <1178559455.2990.99.camel@zod.rchland.ibm.com> Message-ID: <200705071356.25532.jkeating@redhat.com> On Monday 07 May 2007 13:37:35 Josh Boyer wrote: > No. ?f7-final is a tag. ?Rawhide itself (which hasn't actually existed > in a koji based world yet) is comprised of packages that are tagged as > f7-final. > > If there is a package that has been built but not tagged with f7-final, > it's not in rawhide. ?So the state of devel in CVS is not reflective of > either rawhide or the final release at the moment. ?It all depends on > what NVR is tagged with f7-final. What adds to the confusion/frustration is that we did this merger during a freeze. Had we not been frozen, rawhide would be composing from dist-fc7 and it would be much easier to grasp. But we are frozen, and as such there are extra steps involved to get packages "live". Once we branch F-7 and open up rawhide for F8, then rawhide will just compose from things in the standard tag that gets applied when you do 'make build' in devel/ (until the first freeze for F8). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Mon May 7 18:21:39 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 07 May 2007 13:21:39 -0500 Subject: Buildsystem Outage Message-ID: <463F6E33.1040304@redhat.com> We're upgrading some hardware (filers) on Wed, 10:30-12:30 EST. Sorry for any inconvenience. -Mike From mszpak at wp.pl Mon May 7 18:59:15 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Mon, 07 May 2007 20:59:15 +0200 Subject: Merge Status - Building available In-Reply-To: References: <200705031416.00604.jkeating@redhat.com> <463E1BB5.5040101@wp.pl> <200705061125.13876.jkeating@redhat.com> <463E2A72.90203@wp.pl> Message-ID: <463F7703.1030208@wp.pl> On 2007-05-07 3:04:40 +0200, Jason L Tibbitts III wrote: >>>>>> "MZ" == Marcin Zaj?czkowski writes: > > MZ> It would be nice. > > It's also really easy to build python-krbV and koji for FC5; takes a > couple of minutes at most to do two CVS checkouts and run a couple of > makes. I guess if you're competent enough to need koji and you need > it before Jesse can get it built, not having it in the repo shouldn't > be much of an impediment. Thanks for your suggestion. Of course if I needed koji before its appear in FC-5 branch I would try to build it manually, but fortunately all my packages were merged successfully I can wait awhile till next updates. Anyway koji for FC5 would make build easier for a few more packagers in the future. Regards Marcin From notting at redhat.com Mon May 7 19:21:27 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 May 2007 15:21:27 -0400 Subject: confused by f7 vs. f7-final, what koji package shows, and ?tagID In-Reply-To: <200705071337.28885.jkeating@redhat.com> References: <1178557656.26445.68.camel@finch.boston.redhat.com> <200705071337.28885.jkeating@redhat.com> Message-ID: <20070507192127.GC4803@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > First, is there some way to query f7-final packages other than magically > > knowing to use tagID=10 > > koji latest-pkg f7-final > > koji list-tagged f7-final > > browse to tags in koji web, click on f7-final > > etc... Right, however... The primary key in all koji web URLs is the 'id', which is a numeric identifier that has *zero* siginificance to a human user. This is true whether it's the package, the build, the tag, the taks, etc. Is there anyw way to be able to query, via the web, the koji interface with a human-useful identifier? Bill From jkeating at redhat.com Mon May 7 19:27:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 15:27:40 -0400 Subject: confused by f7 vs. f7-final, what koji package shows, and ?tagID In-Reply-To: <20070507192127.GC4803@nostromo.devel.redhat.com> References: <1178557656.26445.68.camel@finch.boston.redhat.com> <200705071337.28885.jkeating@redhat.com> <20070507192127.GC4803@nostromo.devel.redhat.com> Message-ID: <200705071527.40568.jkeating@redhat.com> On Monday 07 May 2007 15:21:27 Bill Nottingham wrote: > Right, however... > > The primary key in all koji web URLs is the 'id', which is a numeric > identifier that has *zero* siginificance to a human user. This is true > whether it's the package, the build, the tag, the taks, etc. > > Is there anyw way to be able to query, via the web, the koji interface > with a human-useful identifier? I don't think so. Sounds like an RFE. You can use the search box to search for various things and go from there currently. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon May 7 19:46:58 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 7 May 2007 22:46:58 +0300 Subject: major change release management for former Extras packages? In-Reply-To: <200705071322.39922.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <20070507171357.GB26384@ryvius.pekin.waw.pl> <200705071322.39922.jkeating@redhat.com> Message-ID: <200705072246.59455.ville.skytta@iki.fi> On Monday 07 May 2007, Jesse Keating wrote: > On Monday 07 May 2007 13:13:57 Dominik 'Rathann' Mierzejewski wrote: > > So... all my unpushed updates would actually be reverted when rawhide is > > open again? > > > > That's... unexpected and ill-conceived, to say the least. Actually it > > stiffles development at this point. It means I can't happily hack away > > even if I'm sure my currently published package set is stable. > > Incorrect. dist-fc8 or dist-f8 or whatever we call it will inherit from > dist-fc7, and thus any unpublished builds will magically show up. But magically only in post-F7 Rawhide, not F7, right? If this is true and I now understand correctly how things proceed from here, there will be lots of ex-Extras packages with broken upgrade paths from FE6 to F7, unless packagers are aware of what exactly they're expected to do and send the corresponding lots of mails to rel-eng and rel-eng accepts and is able to process those mails in time. Assuming all goes well to the point where the mails are actually sent and rel-eng can handle that load during the smallish timeframe there will be available for it before F7, will those packages need to be rebuilt or will the already done builds be just cherry-picked and added to F7 by rel-eng from somewhere? If rebuilt, whose responsibility is it? The current NEVR upgrade checker script in the FE buildsys can produce a report that will clarify the picture somewhat, but only for packages for which some version existed in the Extras devel repository before the merge. Packages introduced anew after the merge and during the freeze will need to be taken care of by other means, or the script hacked to take this into account some way. I think I do understand the goal of this change and it makes mostly sense to me, but I think expecting it to happen within the timeframe left before F7 in an organized manner is a pretty ambitious goal. From jkeating at redhat.com Mon May 7 19:55:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 15:55:56 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <200705072246.59455.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <200705071322.39922.jkeating@redhat.com> <200705072246.59455.ville.skytta@iki.fi> Message-ID: <200705071555.57212.jkeating@redhat.com> On Monday 07 May 2007 15:46:58 Ville Skytt? wrote: > But magically only in post-F7 Rawhide, not F7, right? Correct. > If this is true and I now understand correctly how things proceed from > here, there will be lots of ex-Extras packages with broken upgrade paths > from FE6 to F7, unless packagers are aware of what exactly they're expected > to do and send the corresponding lots of mails to rel-eng and rel-eng > accepts and is able to process those mails in time. ?Assuming all goes well > to the point where the mails are actually sent and rel-eng can handle that > load during the smallish timeframe there will be available for it before > F7, will those packages need to be rebuilt or will the already done builds > be just cherry-picked and added to F7 by rel-eng from somewhere? Presumably the maintainer knew that they were breaking upgrade path when doing the FE6 build, and thus did a build on devel/. Therefor the build would be sitting there, tagged with dist-fc7, waiting for the request and rel-eng to do a simple 'tag-pkg' command. A second's worth of work. > If > rebuilt, whose responsibility is it? It is the responsibility of the maintainer to already have the build complete (and automatically tagged with dist-fc7) before requesting it be tagged for f7-final. > The current NEVR upgrade checker script in the FE buildsys can produce a > report that will clarify the picture somewhat, but only for packages for > which some version existed in the Extras devel repository before the merge. > ? Packages introduced anew after the merge and during the freeze will need > to be taken care of by other means, or the script hacked to take this into > account some way. I fully expect MUCH of our scripts to need some form of work. > I think I do understand the goal of this change and it makes mostly sense > to me, but I think expecting it to happen within the timeframe left before > F7 in an organized manner is a pretty ambitious goal. organized.... or small amounts of chaos... Thankfully tagging a package is extremely quick, it just takes time to generate an email. Things go faster if the rebuilds are to fix NVR only and not "oh, I'm rebuilding, might as well suck down the latest upstream and introduce a soname bump and new features and...." -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Mon May 7 19:51:15 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 14:51:15 -0500 Subject: major change release management for former Extras packages? In-Reply-To: <200705072246.59455.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <20070507171357.GB26384@ryvius.pekin.waw.pl> <200705071322.39922.jkeating@redhat.com> <200705072246.59455.ville.skytta@iki.fi> Message-ID: <1178567475.2990.149.camel@zod.rchland.ibm.com> On Mon, 2007-05-07 at 22:46 +0300, Ville Skytt? wrote: > On Monday 07 May 2007, Jesse Keating wrote: > > On Monday 07 May 2007 13:13:57 Dominik 'Rathann' Mierzejewski wrote: > > > So... all my unpushed updates would actually be reverted when rawhide is > > > open again? > > > > > > That's... unexpected and ill-conceived, to say the least. Actually it > > > stiffles development at this point. It means I can't happily hack away > > > even if I'm sure my currently published package set is stable. > > > > Incorrect. dist-fc8 or dist-f8 or whatever we call it will inherit from > > dist-fc7, and thus any unpublished builds will magically show up. > > But magically only in post-F7 Rawhide, not F7, right? Right. > If this is true and I now understand correctly how things proceed from here, > there will be lots of ex-Extras packages with broken upgrade paths from FE6 > to F7, unless packagers are aware of what exactly they're expected to do and > send the corresponding lots of mails to rel-eng and rel-eng accepts and is > able to process those mails in time. Assuming all goes well to the point > where the mails are actually sent and rel-eng can handle that load during the > smallish timeframe there will be available for it before F7, will those > packages need to be rebuilt or will the already done builds be just > cherry-picked and added to F7 by rel-eng from somewhere? If rebuilt, whose > responsibility is it? If they're built with koji, they get automatically tagged with dist-fc7. Rel-eng will just cherry-pick from there (upon request) and tag the existing package with f7-final. There shouldn't be a rebuild needed to get it into F7. For example, here's a tag request I handled this morning: koji tag-pkg --force f7-final gedit-2.18.0-3.fc7 That took the existing gedit-2.18.0-3.fc7 build that was already tagged with dist-fc7 and tagged it for f7-final. The --force is needed because that tagged is locked. josh From dominik at greysector.net Mon May 7 20:13:31 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 May 2007 22:13:31 +0200 Subject: major change release management for former Extras packages? In-Reply-To: <200705071322.39922.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <1178550074.2990.71.camel@zod.rchland.ibm.com> <20070507171357.GB26384@ryvius.pekin.waw.pl> <200705071322.39922.jkeating@redhat.com> Message-ID: <20070507201331.GB2980@ryvius.pekin.waw.pl> On Monday, 07 May 2007 at 19:22, Jesse Keating wrote: > On Monday 07 May 2007 13:13:57 Dominik 'Rathann' Mierzejewski wrote: > > So... all my unpushed updates would actually be reverted when rawhide is > > open again? > > > > That's... unexpected and ill-conceived, to say the least. Actually it > > stiffles development at this point. It means I can't happily hack away > > even if I'm sure my currently published package set is stable. > > Incorrect. dist-fc8 or dist-f8 or whatever we call it will inherit from > dist-fc7, and thus any unpublished builds will magically show up. OK, I think I understand now. Thanks! Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From ville.skytta at iki.fi Mon May 7 20:42:49 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 7 May 2007 23:42:49 +0300 Subject: major change release management for former Extras packages? In-Reply-To: <200705071555.57212.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705072246.59455.ville.skytta@iki.fi> <200705071555.57212.jkeating@redhat.com> Message-ID: <200705072342.50503.ville.skytta@iki.fi> On Monday 07 May 2007, Jesse Keating wrote: > > Presumably the maintainer knew that they were breaking upgrade path when > doing the FE6 build, and thus did a build on devel/. Well, I didn't until an hour or so ago. And looks like I'm not the only one who missed it. > organized.... or small amounts of chaos... Thankfully tagging a package > is extremely quick, it just takes time to generate an email. Things go > faster if the rebuilds are to fix NVR only and not "oh, I'm rebuilding, > might as well suck down the latest upstream and introduce a soname bump and > new features and...." Understood, and I'm happy to take your word for it if you're saying the whole shebang is doable. I do however think that the sooner an official reminder and a more explicit explanation about things packagers need to take care of (such as things discussed in this thread, eg. what does it mean if I update a package in FE6 and devel now) than what's currently in the Wiki can be sent, the better. From jkeating at redhat.com Mon May 7 20:55:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 16:55:31 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <200705072342.50503.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <200705071555.57212.jkeating@redhat.com> <200705072342.50503.ville.skytta@iki.fi> Message-ID: <200705071655.32032.jkeating@redhat.com> On Monday 07 May 2007 16:42:49 Ville Skytt? wrote: > > Presumably the maintainer knew that they were breaking upgrade path when > > doing the FE6 build, and thus did a build on devel/. > > Well, I didn't until an hour or so ago. ?And looks like I'm not the only > one who missed it. Er, using koji doesn't change this at all. You built something on FC-6/ branch. It may have a higher NVR than the last thing you built on devel/, therefor you need to do a build on devel/. That should all be the same and there should be a build done on devel/. The only missing part _now_ is asking for that already done build on devel/ be tagged for f7-final. > > organized.... ?or small amounts of chaos... ?Thankfully tagging a package > > is extremely quick, it just takes time to generate an email. ?Things go > > faster if the rebuilds are to fix NVR only and not "oh, I'm rebuilding, > > might as well suck down the latest upstream and introduce a soname bump > > and new features and...." > > Understood, and I'm happy to take your word for it if you're saying the > whole shebang is doable. ?I do however think that the sooner an official > reminder and a more explicit explanation about things packagers need to > take care of (such as things discussed in this thread, eg. what does it > mean if I update a package in FE6 and devel now) than what's currently in > the Wiki can be sent, the better. I'd like to send something. I really would. I'd like to have an hour or so to draft it up and make it informative. Unfortunately I'd also like to have a rawhide this week. The most I can commit to doing is answering questions as they come up, as I have a moment or two of not looking at code. :( I do hear though that others are preparing such documents and I will gladly review them for accuracy, and thank them profusely for creating them. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Mon May 7 21:15:24 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 7 May 2007 14:15:24 -0700 (PDT) Subject: [Guidelines Change] Conflicts In-Reply-To: "Tom \"spot\" Callaway"'s message of Monday, 7 May 2007 09:20:45 -0500 <1178547645.3661.19.camel@localhost.localdomain> Message-ID: <20070507211524.278CA1F850C@magilla.localdomain> I've used versioned Conflicts: on other subpackages of my own package. This is necessary because versioned Requires: don't take arch into account, and so don't do everything right in multilib situations. Can the guidelines suggest how to address this? e.g. elfutils-libs has: Conflicts: elfutils-devel < %{version}-%{release} Conflicts: elfutils-devel > %{version}-%{release} Originally elfutils-devel just had: Requires: elfutils-libs = %{version}-%{release} But this doesn't make sure both upgrades happen on a biarch system. This is all because RPM doesn't support: Requires: elfutils-libs = %{version}-%{release}.%{arch} or some syntax with the semantics that implies. The only other way I know that might fix this is: Provides: elfutils-libs-%{arch} = %{version}-%{release} and: Requires: elfutils-libs-%{arch} = %{version}-%{release} But I have not tried this and the Conflicts: method is what I've been using for a few releases. Lines, give me guidance! Thanks, Roland From tcallawa at redhat.com Mon May 7 21:21:13 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 May 2007 16:21:13 -0500 Subject: [Guidelines Change] Conflicts In-Reply-To: <20070507211524.278CA1F850C@magilla.localdomain> References: <20070507211524.278CA1F850C@magilla.localdomain> Message-ID: <1178572873.3661.46.camel@localhost.localdomain> On Mon, 2007-05-07 at 14:15 -0700, Roland McGrath wrote: > I've used versioned Conflicts: on other subpackages of my own package. > This is necessary because versioned Requires: don't take arch into account, > and so don't do everything right in multilib situations. > > Can the guidelines suggest how to address this? > > e.g. elfutils-libs has: > > Conflicts: elfutils-devel < %{version}-%{release} > Conflicts: elfutils-devel > %{version}-%{release} > > Originally elfutils-devel just had: > > Requires: elfutils-libs = %{version}-%{release} > > But this doesn't make sure both upgrades happen on a biarch system. > This is all because RPM doesn't support: > > Requires: elfutils-libs = %{version}-%{release}.%{arch} > > or some syntax with the semantics that implies. > > The only other way I know that might fix this is: > > Provides: elfutils-libs-%{arch} = %{version}-%{release} > > and: > > Requires: elfutils-libs-%{arch} = %{version}-%{release} > > But I have not tried this and the Conflicts: method is what I've been using > for a few releases. First of all, eww. Not because of elfutils, but rpm. OK. I think the Provides/Requires suggestion above is a reasonable workaround, but it might be something we can fix in yum, so it just dtrt in biarch scenarios. I summon Seth Vidal to prove me wrong. ;) ~spot From roland at redhat.com Mon May 7 21:28:30 2007 From: roland at redhat.com (Roland McGrath) Date: Mon, 7 May 2007 14:28:30 -0700 (PDT) Subject: [Guidelines Change] Conflicts In-Reply-To: "Tom \"spot\" Callaway"'s message of Monday, 7 May 2007 16:21:13 -0500 <1178572873.3661.46.camel@localhost.localdomain> Message-ID: <20070507212830.4745E1F850C@magilla.localdomain> > First of all, eww. Not because of elfutils, but rpm. > > OK. I think the Provides/Requires suggestion above is a reasonable > workaround, but it might be something we can fix in yum, so it just dtrt > in biarch scenarios. rpm itself ought to be changed too. Otherwise using rpm by hand to upgrade elfutils-devel.i386 and elfutils-libs.x86_64 can leave elfutils-devel.x86_64 an old one that failed to properly conflict with upgrading elfutils-libs. From jkeating at redhat.com Mon May 7 21:39:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 17:39:04 -0400 Subject: [Guidelines Change] Conflicts In-Reply-To: <20070507212830.4745E1F850C@magilla.localdomain> References: <20070507212830.4745E1F850C@magilla.localdomain> Message-ID: <200705071739.04757.jkeating@redhat.com> On Monday 07 May 2007 17:28:30 Roland McGrath wrote: > rpm itself ought to be changed too. ?Otherwise using rpm by hand to upgrade > elfutils-devel.i386 and elfutils-libs.x86_64 can leave > elfutils-devel.x86_64 an old one that failed to properly conflict with > upgrading elfutils-libs. That may have been the case a while ago, but now if you have a .so symlink in your -devel package, it will have a proper file level requirement on the arch specific -libs (or base) package that the symlink points to. If you have both elfutils-devel.x86_64 and elfutils-libs.x86_64 and elfutils-libs.i386 and tried to upgrade just elfutils-libs.x86_64 and elfutils-devel.i386 it would fail. elfutils-devel.x86_64 would have a file requires on the soname that is only provided by elfutils-libs.x86_64 of the matching version. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon May 7 21:39:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 7 May 2007 23:39:50 +0200 Subject: [Guidelines Change] Conflicts In-Reply-To: <20070507211524.278CA1F850C@magilla.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> <20070507211524.278CA1F850C@magilla.localdomain> Message-ID: <20070507213950.GG8740@neu.nirvana> On Mon, May 07, 2007 at 02:15:24PM -0700, Roland McGrath wrote: > I've used versioned Conflicts: on other subpackages of my own package. > This is necessary because versioned Requires: don't take arch into account, > and so don't do everything right in multilib situations. > > Can the guidelines suggest how to address this? > > e.g. elfutils-libs has: > > Conflicts: elfutils-devel < %{version}-%{release} > Conflicts: elfutils-devel > %{version}-%{release} I would consider that a neccessary evil. BTW rpm itself needs BuildConflicts against rpm-devel != self, as otherwise the build picks up the wrong rpm headers. Thank god that modern packaging happens in minimal spawned build environments otherwise we would need BuildConflicts all over the map. > Lines, give me guidance! I think what you do qualifies as fine to deal with it that way. And BTW who is "Lines"? :) The lack of arch in setting up dependencies has been an often topic on rpm devel lists, and AFAIK the rpm god's version even has support for it by now, but AFAIK2 it breaks all backward compatibility. But maybe this breakage is worth while. Probably best discussed on rpm-maint lists. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon May 7 21:45:41 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 8 May 2007 00:45:41 +0300 Subject: major change release management for former Extras packages? In-Reply-To: <200705071655.32032.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705072342.50503.ville.skytta@iki.fi> <200705071655.32032.jkeating@redhat.com> Message-ID: <200705080045.41869.ville.skytta@iki.fi> On Monday 07 May 2007, Jesse Keating wrote: > On Monday 07 May 2007 16:42:49 Ville Skytt? wrote: > > > Presumably the maintainer knew that they were breaking upgrade path > > > when doing the FE6 build, and thus did a build on devel/. > > > > Well, I didn't until an hour or so ago. ?And looks like I'm not the only > > one who missed it. > > Er, using koji doesn't change this at all. You built something on FC-6/ > branch. It may have a higher NVR than the last thing you built on devel/, > therefor you need to do a build on devel/. That should all be the same and > there should be a build done on devel/. The only missing part _now_ is > asking for that already done build on devel/ be tagged for f7-final. Sure. It appears I misread your sentence quoted above, but nevermind. I think the tag names are the things that misled me; I thought f7-final == set of packages that are in F7 the day it is released (pretty self explanatory tag name), and dist-f7 == set of packages that get automatically rolled into F7 repositories as updates after the release or something, but definitely included anyway - "dist-f7" expands naturally into "distributed in F7" or "part of the F7 distribution" when I read it. So now my understanding is that dist-f7 is not the above, but rather kind of a queue for builds possibly to be included in F7 later based on some criteria, primarily if the maintainer asks and rel-eng approves. I think I wouldn't have been nearly that confused if dist-f7 would have been called eg. f7-queue, f7-candidate, f7-pending or something along those lines. From j.w.r.degoede at hhs.nl Mon May 7 22:02:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 00:02:57 +0200 Subject: [Guidelines Change] Conflicts In-Reply-To: <200705071739.04757.jkeating@redhat.com> References: <20070507212830.4745E1F850C@magilla.localdomain> <200705071739.04757.jkeating@redhat.com> Message-ID: <463FA211.5060403@hhs.nl> Jesse Keating wrote: > On Monday 07 May 2007 17:28:30 Roland McGrath wrote: >> rpm itself ought to be changed too. Otherwise using rpm by hand to upgrade >> elfutils-devel.i386 and elfutils-libs.x86_64 can leave >> elfutils-devel.x86_64 an old one that failed to properly conflict with >> upgrading elfutils-libs. > > That may have been the case a while ago, but now if you have a .so symlink in > your -devel package, it will have a proper file level requirement on the arch > specific -libs (or base) package that the symlink points to. If you have > both elfutils-devel.x86_64 and elfutils-libs.x86_64 and elfutils-libs.i386 > and tried to upgrade just elfutils-libs.x86_64 and elfutils-devel.i386 it > would fail. elfutils-devel.x86_64 would have a file requires on the soname > that is only provided by elfutils-libs.x86_64 of the matching version. > Only if the soname changed, otherwise rpm will get it wrong. (been there accidently done that). This whole multilib stuff isn't pretty ideally rpm would be fixed so that all packages would automaticly provide not only %{name} = %{version-%{release}, but also %{name} = %{version-%{release}.%{arch} And then the Requires for -devel's would get the %{arch} added too, or we could add both the provides and the requires manually for all packages with a -devel sub. Regards, Hans p.s. the Conflicts uee in elflib is evil and should be abolished From j.w.r.degoede at hhs.nl Mon May 7 22:10:49 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 May 2007 00:10:49 +0200 Subject: [Guidelines Change] Conflicts In-Reply-To: <1178547645.3661.19.camel@localhost.localdomain> References: <1178547645.3661.19.camel@localhost.localdomain> Message-ID: <463FA3E9.9050003@hhs.nl> Tom "spot" Callaway wrote: > Library Name Conflicts > * Put the library in a subdirectory of /usr/lib or /lib and > include a ld.so.conf file in /etc/ld.so.conf.d/. > Erm, that may make rpm happy, but will confuse the hell out of ld.so, which is not a good idea. Especially since the newer / odder library which uses this hack will be found first. Instead when a new lib gets added with a conflicting soname, then the packager should change the soname. Since we have no packages uses it (yet) this shouldn't break any existing packages. Yes this will require patches for packages which want to build against this, but its better then confusing ld.so Example. currently we have an xmlrpc-c package in FE which provides /usr/lib[64]/libxmplrpc.so.0 But we also have xmlrpc-efi under review, which also provides /usr/lib[64]/libxmplrpc.so.0 Both with normal sonames, iow both with sonames == filename, now if we would fix that by putting the one of xmlrpc-efi in a subdir under /usr/lib[64], and add a ld.so.conf file. Then user who install both will have there xmlrpc-c uisng apps go kaplowey, as they will get linked against the xmlrpc-efi one, as that is in ld.so.conf and ld.so.conf listed dirs are searched before the default lib dirs. Thus I've requested the xmlrpc-efi submitter to rename the lib too: /usr/lib[64]/libxmplrpc-efi.so.0 And adjust the soname accordingly. Regards, Hans From jkeating at redhat.com Mon May 7 21:59:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 17:59:06 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <200705080045.41869.ville.skytta@iki.fi> References: <200705031416.00604.jkeating@redhat.com> <200705071655.32032.jkeating@redhat.com> <200705080045.41869.ville.skytta@iki.fi> Message-ID: <200705071759.07069.jkeating@redhat.com> On Monday 07 May 2007 17:45:41 Ville Skytt? wrote: > So now my understanding is that dist-f7 is not the above, but rather kind > of a queue for builds possibly to be included in F7 later based on some > criteria, primarily if the maintainer asks and rel-eng approves. ?I think I > wouldn't have been nearly that confused if dist-f7 would have been called > eg. f7-queue, f7-candidate, f7-pending or something along those lines. I think your right, it's difficult to introduce these tags/concepts in the middle of a freeze. Had we done this a while back, things would have made sense. dist-fc7 is where things are landing, headed toward Fedora 7 release. f7-final is a new tag that got created at the freeze point to start tracking all the stuff that's approved for final, dist-fc7 is just where things continue to land. Confusing, I know :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon May 7 23:11:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 May 2007 04:41:56 +0530 Subject: mailing list header and web interface descriptions Message-ID: <463FB23C.5030907@fedoraproject.org> Hi $subject would require a cleanup to remove references to Fedora Core and Fedora Extras in the all the current Fedora mailing lists and outdated content should be removed or updated. Is there anyone who has admin access to all of them? rahul From jwboyer at jdub.homelinux.org Tue May 8 01:44:52 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 20:44:52 -0500 Subject: major change release management for former Extras packages? In-Reply-To: <200705071655.32032.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705071555.57212.jkeating@redhat.com> <200705072342.50503.ville.skytta@iki.fi> <200705071655.32032.jkeating@redhat.com> Message-ID: <1178588692.25550.4.camel@vader.jdub.homelinux.org> On Mon, 2007-05-07 at 16:55 -0400, Jesse Keating wrote: > On Monday 07 May 2007 16:42:49 Ville Skytt? wrote: > > > Presumably the maintainer knew that they were breaking upgrade path when > > > doing the FE6 build, and thus did a build on devel/. > > > > Well, I didn't until an hour or so ago. And looks like I'm not the only > > one who missed it. > > Er, using koji doesn't change this at all. You built something on FC-6/ > branch. It may have a higher NVR than the last thing you built on devel/, > therefor you need to do a build on devel/. That should all be the same and > there should be a build done on devel/. The only missing part _now_ is > asking for that already done build on devel/ be tagged for f7-final. > > > > organized.... or small amounts of chaos... Thankfully tagging a package > > > is extremely quick, it just takes time to generate an email. Things go > > > faster if the rebuilds are to fix NVR only and not "oh, I'm rebuilding, > > > might as well suck down the latest upstream and introduce a soname bump > > > and new features and...." > > > > Understood, and I'm happy to take your word for it if you're saying the > > whole shebang is doable. I do however think that the sooner an official > > reminder and a more explicit explanation about things packagers need to > > take care of (such as things discussed in this thread, eg. what does it > > mean if I update a package in FE6 and devel now) than what's currently in > > the Wiki can be sent, the better. > > I'd like to send something. I really would. I'd like to have an hour or so > to draft it up and make it informative. Unfortunately I'd also like to have > a rawhide this week. The most I can commit to doing is answering questions > as they come up, as I have a moment or two of not looking at code. :( > > I do hear though that others are preparing such documents and I will gladly > review them for accuracy, and thank them profusely for creating them. I'm actually typing something up now. josh From jwboyer at jdub.homelinux.org Tue May 8 03:00:38 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 07 May 2007 22:00:38 -0500 Subject: Post-merge howto and FAQ Message-ID: <1178593238.25550.10.camel@vader.jdub.homelinux.org> Hi All, Due to popular demand, I sat down and wrote up a brief howto for handling packages in the merged world. Given that I'm almost guaranteed to have not answered all the questions, it's living under: http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO for the moment. Hopefully it will give the package maintainers a high level overview of what to do and how to do it. Feel free to ask questions and I (or others) will try to address them. Once we get a decent enough document in place, the content can be generalized and we'll update the main packaging documents with the appropriate information. josh From dev at nigelj.com Tue May 8 03:20:04 2007 From: dev at nigelj.com (Nigel Jones) Date: Tue, 8 May 2007 15:20:04 +1200 (NZST) Subject: Post-merge howto and FAQ In-Reply-To: <1178593238.25550.10.camel@vader.jdub.homelinux.org> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> Message-ID: <18010.202.74.202.139.1178594404.squirrel@webmail.nigelj.com> > Hi All, > > Due to popular demand, I sat down and wrote up a brief howto for > handling packages in the merged world. Given that I'm almost guaranteed > to have not answered all the questions, it's living under: > > http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO > > for the moment. Hopefully it will give the package maintainers a high > level overview of what to do and how to do it. Feel free to ask > questions and I (or others) will try to address them. > > Once we get a decent enough document in place, the content can be > generalized and we'll update the main packaging documents with the > appropriate information. > > josh Very nice article, only one question/thing that could be added: How does this effect new packages going through package review? As an example: windowlab (new package, added just before merge), was imported into plague with fe7-merge as a tag, fe7-merge is inherited by f7-final, so I'm assuming here that they are included. ocaml-{SDL,camlimages} & freetennis (new packages, can't be built quite yet but were added to Koji after merge) are all set to have dist-f7. Will I when they are built, have to ask releng to add them to f7-final? (It'd seem a bit weird going freetennis in FC-6, not in F-7 but in F-8 ;)) N.J. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From jkeating at redhat.com Tue May 8 03:25:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 May 2007 20:25:25 -0700 Subject: Post-merge howto and FAQ In-Reply-To: <18010.202.74.202.139.1178594404.squirrel@webmail.nigelj.com> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <18010.202.74.202.139.1178594404.squirrel@webmail.nigelj.com> Message-ID: <200705072025.26246.jkeating@redhat.com> On Monday 07 May 2007 20:20:04 Nigel Jones wrote: > ocaml-{SDL,camlimages} & freetennis (new packages, can't be built quite > yet but were added to Koji after merge) are all set to have dist-f7. ?Will > I when they are built, have to ask releng to add them to f7-final? (It'd > seem a bit weird going freetennis in FC-6, not in F-7 but in F-8 ;)) Yes, you'll have to ask for them. We're pretty open to new packages, so long as they don't destroy the repo (: Just don't expect them to necessarily make it into any named spin. Think carefully before adding them as a mandatory/default in comps. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dev at nigelj.com Tue May 8 03:38:12 2007 From: dev at nigelj.com (Nigel Jones) Date: Tue, 8 May 2007 15:38:12 +1200 (NZST) Subject: Post-merge howto and FAQ In-Reply-To: <200705072025.26246.jkeating@redhat.com> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <18010.202.74.202.139.1178594404.squirrel@webmail.nigelj.com> <200705072025.26246.jkeating@redhat.com> Message-ID: <20775.202.74.202.139.1178595492.squirrel@webmail.nigelj.com> > On Monday 07 May 2007 20:20:04 Nigel Jones wrote: >> ocaml-{SDL,camlimages} & freetennis (new packages, can't be built quite >> yet but were added to Koji after merge) are all set to have dist-f7. >> Will >> I when they are built, have to ask releng to add them to f7-final? (It'd >> seem a bit weird going freetennis in FC-6, not in F-7 but in F-8 ;)) > > Yes, you'll have to ask for them. We're pretty open to new packages, so > long > as they don't destroy the repo (: Just don't expect them to necessarily > make > it into any named spin. Think carefully before adding them as a > mandatory/default in comps. Understood now, thanks for the clarification, and I don't think they'll be entering comps as mandatory/default, but thanks for reminding me that they need to be entered as optional at some point. > > -- > Jesse Keating > Release Engineer: Fedora > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From dcm at acm.org Tue May 8 04:11:46 2007 From: dcm at acm.org (David Moore) Date: Tue, 08 May 2007 00:11:46 -0400 Subject: Post-merge howto and FAQ In-Reply-To: <1178593238.25550.10.camel@vader.jdub.homelinux.org> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> Message-ID: <1178597506.26794.15.camel@PISCES.MIT.EDU> That's very helpful, thanks. One question: Presumably there is a date at which getting tagged with "f7-final" will stop meaning "goes in the Fedora 7 gold release" and will start meaning "goes in the Fedora 7 updates repository"? How is this date decided and what kind of warning will we get before it happens? Also, in FC6 and earlier, the release and updates were stored in separate repositories on the server. Will those continue to be separate, or will they be merged in F7? Thanks, David On Mon, 2007-05-07 at 22:00 -0500, Josh Boyer wrote: > Hi All, > > Due to popular demand, I sat down and wrote up a brief howto for > handling packages in the merged world. Given that I'm almost guaranteed > to have not answered all the questions, it's living under: > > http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO > > for the moment. Hopefully it will give the package maintainers a high > level overview of what to do and how to do it. Feel free to ask > questions and I (or others) will try to address them. > > Once we get a decent enough document in place, the content can be > generalized and we'll update the main packaging documents with the > appropriate information. > > josh > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jpmahowald at gmail.com Tue May 8 05:02:19 2007 From: jpmahowald at gmail.com (John Mahowald) Date: Tue, 8 May 2007 00:02:19 -0500 Subject: Orphaned package: pam_usb In-Reply-To: <462F70BF.4050806@odu.neva.ru> References: <462F70BF.4050806@odu.neva.ru> Message-ID: <3ea997540705072202h562dcfbdvf597a22aaca24fb0@mail.gmail.com> On 4/25/07, Dmitry Butskoy wrote: > I am not interested in this package now, feel free to get it. > > BTW, a new version 0.4.0 is available at http://www.pamusb.org . > > Regards, > Dmitry Butskoy > I'm interested in taking and updating to 0.4.0. I'll take ownership unless there are objections. John From opensource at till.name Tue May 8 07:33:06 2007 From: opensource at till.name (Till Maas) Date: Tue, 08 May 2007 09:33:06 +0200 Subject: Post-merge howto and FAQ In-Reply-To: <1178593238.25550.10.camel@vader.jdub.homelinux.org> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> Message-ID: <200705080933.12493.opensource@till.name> Hiyas, as far as I understand the new process, there should be a big fat warning given to Extras maintainers not to update their FE 6 and 5 packages (except for adding an integer after the dist-tag) before the release team allowed an update for F7. Otherwise the upgrade path will be broken. Or am I wrong? Example: currently in FE6 is fatsort-0.9.7-1.fc6 in F7 fatsort is locket to 0.9.7-1.fc7 So when I update fatsort in FE6 to fatsort-0.9.7.1-1.fc6 it cannot upgrade in F7. Or are FE6 builds now also locked down? Regards, Till From opensource at till.name Tue May 8 07:48:20 2007 From: opensource at till.name (Till Maas) Date: Tue, 08 May 2007 09:48:20 +0200 Subject: major change release management for former Extras packages? In-Reply-To: <200705071759.07069.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705080045.41869.ville.skytta@iki.fi> <200705071759.07069.jkeating@redhat.com> Message-ID: <200705080948.22880.opensource@till.name> On Mo Mai 7 2007, Jesse Keating wrote: > Had we done this a while back, things would have made sense. dist-fc7 is > where things are landing, headed toward Fedora 7 release. f7-final is a > new tag that got created at the freeze point to start tracking all the > stuff that's approved for final, dist-fc7 is just where things continue to > land. Confusing, I know :/ On http://koji.fedoraproject.org/koji/tags there is so much space, maybe someone can add a description to each tag that explains what the tag is there for. Another confusing issue is that "Targets building to this tag" and "Targets building from this tag" on http://koji.fedoraproject.org/koji/taginfo?tagID=10 link to the same pagem is this really wanted and what does it mean? Will the time format in koji be configurable? Or can someone configure the default beeing UTC? Or at least can the timezone be displayed in an offset to UTC? Regards, Till From opensource at till.name Tue May 8 07:53:12 2007 From: opensource at till.name (Till Maas) Date: Tue, 08 May 2007 09:53:12 +0200 Subject: Buildsystem Outage In-Reply-To: <463F6E33.1040304@redhat.com> References: <463F6E33.1040304@redhat.com> Message-ID: <200705080953.13239.opensource@till.name> On Mo Mai 7 2007, Mike McGrath wrote: > Wed, 10:30-12:30 EST. Would you please annonces dates and times also in UTC or also mention the offset to UTC in addition to the abbreviation of the timezone? This would make it a lot easier for me and others that are in another timezone to know when this actually is. Regards, Till From twaugh at redhat.com Tue May 8 08:52:21 2007 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 08 May 2007 09:52:21 +0100 Subject: Buildsystem Outage In-Reply-To: <200705080953.13239.opensource@till.name> References: <463F6E33.1040304@redhat.com> <200705080953.13239.opensource@till.name> Message-ID: <1178614341.6582.8.camel@cyberelk.elk> On Tue, 2007-05-08 at 09:53 +0200, Till Maas wrote: > Would you please annonces dates and times also in UTC or also mention the > offset to UTC in addition to the abbreviation of the timezone? This would > make it a lot easier for me and others that are in another timezone to know > when this actually is. ..and don't forget, this is really easy to do -- even when the arranged date is the other side of a time zone boundary -- with the international-time program from Extras. yum install international-time Tim. */ -------------- 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 opensource at till.name Tue May 8 10:02:29 2007 From: opensource at till.name (Till Maas) Date: Tue, 08 May 2007 12:02:29 +0200 Subject: major change release management for former Extras packages? In-Reply-To: <200705071555.57212.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705072246.59455.ville.skytta@iki.fi> <200705071555.57212.jkeating@redhat.com> Message-ID: <200705081202.31051.opensource@till.name> On Mo Mai 7 2007, Jesse Keating wrote: > organized.... or small amounts of chaos... Thankfully tagging a package > is extremely quick, it just takes time to generate an email. Things go Why is this not integrated in koji, e.g. a button "request tag" for a package? Internally it may send an email to the release engeneering team, for maintainers imho it would be easier when there is one frontend and not a frontend and several e-mail adressess. Also the ability to remove packages from the repository or stopping them to go into one would be nice, afaik this has to be done with some e-mail, too. Regards, Till From jkeating at redhat.com Tue May 8 10:26:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 8 May 2007 06:26:43 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <200705081202.31051.opensource@till.name> References: <200705031416.00604.jkeating@redhat.com> <200705071555.57212.jkeating@redhat.com> <200705081202.31051.opensource@till.name> Message-ID: <200705080626.46909.jkeating@redhat.com> On Tuesday 08 May 2007 06:02:29 Till Maas wrote: > Why is this not integrated in koji, e.g. a button "request tag" for a > package? Internally it may send an email to the release engeneering team, > for maintainers imho it would be easier when there is one frontend and not > a frontend and several e-mail adressess. Also the ability to remove > packages from the repository or stopping them to go into one would be nice, > afaik this has to be done with some e-mail, too. Because that feature just hasn't been written. The code is open source, patches welcome. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue May 8 10:39:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 05:39:59 -0500 Subject: Post-merge howto and FAQ In-Reply-To: <200705080933.12493.opensource@till.name> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <200705080933.12493.opensource@till.name> Message-ID: <1178620800.25550.14.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 09:33 +0200, Till Maas wrote: > Hiyas, > > as far as I understand the new process, there should be a big fat warning > given to Extras maintainers not to update their FE 6 and 5 packages (except > for adding an integer after the dist-tag) before the release team allowed an > update for F7. Otherwise the upgrade path will be broken. Or am I wrong? > > Example: > > currently in FE6 is fatsort-0.9.7-1.fc6 > in F7 fatsort is locket to 0.9.7-1.fc7 > > So when I update fatsort in FE6 to fatsort-0.9.7.1-1.fc6 it cannot upgrade in > F7. Or are FE6 builds now also locked down? FE[56] builds are not locked down. You bring up a very good point about the upgrade path. I will add it to the page. Essentially, if you're upgrading a package across f7 and fe[56], the easiest way to do so and not break the upgrade path is to upgrade f7, submit the request to rel-eng, then upgrade fe[56] after the f7 build has been tagged. You don't _need_ to do it in that order, but it's the most "fail-safe". josh From jwboyer at jdub.homelinux.org Tue May 8 10:42:49 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 05:42:49 -0500 Subject: Post-merge howto and FAQ In-Reply-To: <1178597506.26794.15.camel@PISCES.MIT.EDU> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <1178597506.26794.15.camel@PISCES.MIT.EDU> Message-ID: <1178620969.25550.17.camel@vader.jdub.homelinux.org> On Tue, 2007-05-08 at 00:11 -0400, David Moore wrote: > That's very helpful, thanks. > > One question: Presumably there is a date at which getting tagged with > "f7-final" will stop meaning "goes in the Fedora 7 gold release" and > will start meaning "goes in the Fedora 7 updates repository"? How is > this date decided and what kind of warning will we get before it > happens? Actually, the updates to Fedora 7 will have a different tag. Likely f7-updates or something (Jesse would know for sure). As to when that occurs, it will likely go active right around the time we declare F7 as golden. And yes, there should be an email explaining the update procedure when it's ready. > > Also, in FC6 and earlier, the release and updates were stored in > separate repositories on the server. Will those continue to be > separate, or will they be merged in F7? Updates will continue to be stored in a separate repo as far as I know. josh From opensource at till.name Tue May 8 11:57:42 2007 From: opensource at till.name (Till Maas) Date: Tue, 08 May 2007 13:57:42 +0200 Subject: major change release management for former Extras packages? In-Reply-To: <200705080626.46909.jkeating@redhat.com> References: <200705031416.00604.jkeating@redhat.com> <200705081202.31051.opensource@till.name> <200705080626.46909.jkeating@redhat.com> Message-ID: <200705081357.43475.opensource@till.name> On Di Mai 8 2007, Jesse Keating wrote: > Because that feature just hasn't been written. The code is open source, > patches welcome. I would like to. Can you explain me, how to add a new "request handler"? The documentation is imho very poor. Is it enough to add a def requesttag(req, buildID, tagID=None): in www/kojiweb/index.py and a requesttag.chtml? (and all the stuff that needs to be done to process the request, too, of corse) I would change the Tags descroption to "Tags (Request Tag)" in buildinfo.chtml, so to use requesttag?buildID=$build.id to get a page where one can select which tag he wants to request and add some comments why, what he tested, etc. (all the stuff that is written in the Wiki) and the submit button should then go to requesttag?buildID=$build.id&tagID=1234 where 1234 is the ID of the requested tag. Regards, Till From jkeating at redhat.com Wed May 9 01:05:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 8 May 2007 21:05:43 -0400 Subject: major change release management for former Extras packages? In-Reply-To: <200705081357.43475.opensource@till.name> References: <200705031416.00604.jkeating@redhat.com> <200705080626.46909.jkeating@redhat.com> <200705081357.43475.opensource@till.name> Message-ID: <200705082105.44210.jkeating@redhat.com> On Tuesday 08 May 2007 07:57:42 Till Maas wrote: > On Di Mai 8 2007, Jesse Keating wrote: > > Because that feature just hasn't been written. The code is open source, > > patches welcome. > > I would like to. Can you explain me, how to add a new "request handler"? > The documentation is imho very poor. Is it enough to add a > > def requesttag(req, buildID, tagID=None): > > in www/kojiweb/index.py and a requesttag.chtml? (and all the stuff that > needs to be done to process the request, too, of corse) > > I would change the Tags descroption to "Tags ( href="requesttag?buildID=$build.id">Request Tag)" in > buildinfo.chtml, so to use > > requesttag?buildID=$build.id to get a page where one can select which tag > he wants to request and add some comments why, what he tested, etc. (all > the stuff that is written in the Wiki) and the submit button should then go > to > > requesttag?buildID=$build.id&tagID=1234 > > where 1234 is the ID of the requested tag. This is best continued on fedora-buildsys-list at redhat.com or in the Koji trac page (http://hosted.fedoraprojects.org/projects/koji) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed May 9 01:24:43 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 08 May 2007 20:24:43 -0500 Subject: [Announcement] Fedora 7 Deep Freeze/GA release schedule change Message-ID: <1178673883.3175.109.camel@vader.jdub.homelinux.org> The bulk of the Core/Extras merge has now been finished, and the Release Engineering team has been working hard to get things back in shape for the final F7 release. However, due to the massive nature of this undertaking, we are not coming back online as fast as we had hoped. We do not have a rawhide repository available as of yet, and the release and QA teams are not comfortable going into deep freeze at this point. During the Release team meeting yesterday, it was decided to slip the deep freeze date by a week at least. This will also slip the final release of Fedora 7 by at least a week. Slipping a week will allow more time for the merge tree to materialize and stabilize. Maintainers will also have more time to adjust to the new processes involved as a result of the merge. We will also have more time to evaluate the blocking bugs that are currently open in Bugzilla. While this slip is unfortunate, it is also in the best interest for the quality of the release. Please bear with us as we strive to make this the best release of Fedora to date! josh From pertusus at free.fr Wed May 9 07:56:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 9 May 2007 09:56:10 +0200 Subject: are plague builds for devel disabled? Message-ID: <20070509075610.GB2851@free.fr> Hello, The subject says it all. Also have the packages that needed to be pushed flushed (I biult the libdap stack it was a mistake and wisely Michael didn't pushed them, maybe other packages are in a similar state or in other problematic states)? -- Pat From pertusus at free.fr Wed May 9 08:03:20 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 9 May 2007 10:03:20 +0200 Subject: [Announcement] Fedora 7 Deep Freeze/GA release schedule change In-Reply-To: <1178673883.3175.109.camel@vader.jdub.homelinux.org> References: <1178673883.3175.109.camel@vader.jdub.homelinux.org> Message-ID: <20070509080320.GC2851@free.fr> On Tue, May 08, 2007 at 08:24:43PM -0500, Josh Boyer wrote: > > Slipping a week will allow more time for the merge tree to materialize > and stabilize. Maintainers will also have more time to adjust to the > new processes involved as a result of the merge. We will also have more > time to evaluate the blocking bugs that are currently open in Bugzilla. As a fedora extras developper I think it wouldn't be bad if we have time to adapt to all the changes (koji, release process) and if there was time to properly document the changes before F7 is out, and have time to understand everything. It may also be nice to know precisely how updates will be done before the release. Maybe the adaptation may also take place between the freeze and the release, but I guess this period of time should be short too. -- Pat From bugs.michael at gmx.net Wed May 9 08:26:45 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 9 May 2007 10:26:45 +0200 Subject: are plague builds for devel disabled? In-Reply-To: <20070509075610.GB2851@free.fr> References: <20070509075610.GB2851@free.fr> Message-ID: <20070509102645.6902b201.bugs.michael@gmx.net> On Wed, 9 May 2007 09:56:10 +0200, Patrice Dumas wrote: > Hello, > > The subject says it all. Also have the packages that needed to be > pushed flushed (I biult the libdap stack it was a mistake and wisely > Michael didn't pushed them, maybe other packages are in a similar > state or in other problematic states)? There are no packages left in plague devel needsign. I assume plague builds for devel are disabled fully, because every build done with plague would have to be imported into koji manually, and meanwhile koji has built lots of packages against a divergent tree anyway (dist-fc7 contains packages not available to plague). From dennis at ausil.us Wed May 9 11:42:47 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 9 May 2007 06:42:47 -0500 Subject: are plague builds for devel disabled? In-Reply-To: <20070509102645.6902b201.bugs.michael@gmx.net> References: <20070509075610.GB2851@free.fr> <20070509102645.6902b201.bugs.michael@gmx.net> Message-ID: <200705090642.57367.dennis@ausil.us> Once upon a time Wednesday 09 May 2007, Michael Schwendt wrote: > On Wed, 9 May 2007 09:56:10 +0200, Patrice Dumas wrote: > > Hello, > > > > The subject says it all. Also have the packages that needed to be > > pushed flushed (I biult the libdap stack it was a mistake and wisely > > Michael didn't pushed them, maybe other packages are in a similar > > state or in other problematic states)? > > There are no packages left in plague devel needsign. I assume plague > builds for devel are disabled fully, because every build done with plague > would have to be imported into koji manually, and meanwhile koji has built > lots of packages against a divergent tree anyway (dist-fc7 contains > packages not available to plague). plague is completely disabled from building devel. you need to update your common dir first then make build or make koji will work. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Wed May 9 13:00:43 2007 From: opensource at till.name (Till Maas) Date: Wed, 09 May 2007 15:00:43 +0200 Subject: Packaging Haskell libraries Message-ID: <200705091500.43803.opensource@till.name> Hiyas, I want to test a new window manager (http://xmonad.org/) and maybe package it for Fedora. It is written in Haskell and needs some libraries: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-1.2 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-extras-0.1 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mtl-1.0 So I guess the libraries should have a common prefix in Fedora, like Perl/Ruby/Python libraries have, too. Is packaging them as haskell-X11 haskell-X11-extras haskell-mtl ok? Do I need to ask FESCO or the FPC for this? It seems to me, that there are no Haskell libraries available in Fedora, right now. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed May 9 13:20:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 08:20:27 -0500 Subject: [Announcement] Fedora 7 Deep Freeze/GA release schedule change In-Reply-To: <1178673883.3175.109.camel@vader.jdub.homelinux.org> References: <1178673883.3175.109.camel@vader.jdub.homelinux.org> Message-ID: <1178716827.3086.14.camel@zod.rchland.ibm.com> On Tue, 2007-05-08 at 20:24 -0500, Josh Boyer wrote: > The bulk of the Core/Extras merge has now been finished, and the Release > Engineering team has been working hard to get things back in shape for > the final F7 release. However, due to the massive nature of this > undertaking, we are not coming back online as fast as we had hoped. > > We do not have a rawhide repository available as of yet, and the release > and QA teams are not comfortable going into deep freeze at this point. > During the Release team meeting yesterday, it was decided to slip the > deep freeze date by a week at least. This will also slip the final > release of Fedora 7 by at least a week. > > Slipping a week will allow more time for the merge tree to materialize > and stabilize. Maintainers will also have more time to adjust to the > new processes involved as a result of the merge. We will also have more > time to evaluate the blocking bugs that are currently open in Bugzilla. > > While this slip is unfortunate, it is also in the best interest for the > quality of the release. Please bear with us as we strive to make this > the best release of Fedora to date! Also, given that release cycles for older Fedora releases are dependent upon the release dates of future releases, Fedora Core 5 will have it's EOL date extended the same amount of time as the Fedora 7 release slips. FYI. josh From gemi at bluewin.ch Wed May 9 13:55:53 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 09 May 2007 15:55:53 +0200 Subject: Packaging Haskell libraries In-Reply-To: <200705091500.43803.opensource@till.name> References: <200705091500.43803.opensource@till.name> Message-ID: <1178718953.2619.0.camel@localhost.localdomain> On Wed, 2007-05-09 at 15:00 +0200, Till Maas wrote: > Is packaging them as > > haskell-X11 > haskell-X11-extras > haskell-mtl > > ok? Do I need to ask FESCO or the FPC for this? It seems to me, that > there are > no Haskell libraries available in Fedora, right now. There is gtk2hs in Extras. I presume you use ghc, maybe you look at how gtk2hs is packaged. > -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From mmcgrath at redhat.com Wed May 9 14:49:12 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 09 May 2007 09:49:12 -0500 Subject: Buildsystem Outage In-Reply-To: <200705080953.13239.opensource@till.name> References: <463F6E33.1040304@redhat.com> <200705080953.13239.opensource@till.name> Message-ID: <4641DF68.1070509@redhat.com> Till Maas wrote: > On Mo Mai 7 2007, Mike McGrath wrote: > >> Wed, 10:30-12:30 EST. >> > > Would you please annonces dates and times also in UTC or also mention the > offset to UTC in addition to the abbreviation of the timezone? This would > make it a lot easier for me and others that are in another timezone to know > when this actually is. > This is a good idea in general, we'll try to make a point of using UTC from now on. -Mike From a.badger at gmail.com Wed May 9 14:57:10 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 09 May 2007 07:57:10 -0700 Subject: Packaging Haskell libraries In-Reply-To: <200705091500.43803.opensource@till.name> References: <200705091500.43803.opensource@till.name> Message-ID: <1178722630.5869.69.camel@localhost.localdomain> On Wed, 2007-05-09 at 15:00 +0200, Till Maas wrote: > Hiyas, > > I want to test a new window manager (http://xmonad.org/) and maybe package it > for Fedora. > > It is written in Haskell and needs some libraries: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-1.2 > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-extras-0.1 > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mtl-1.0 > > So I guess the libraries should have a common prefix in Fedora, like > Perl/Ruby/Python libraries have, too. > > Is packaging them as > > haskell-X11 > haskell-X11-extras > haskell-mtl > > ok? Do I need to ask FESCO or the FPC for this? It seems to me, that there are > no Haskell libraries available in Fedora, right now. > That sounds good. The ocaml guidelines that are currently in draft form use a prefix of ocaml- as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Wed May 9 15:03:18 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 May 2007 17:03:18 +0200 Subject: Packaging Haskell libraries In-Reply-To: <1178722630.5869.69.camel@localhost.localdomain> References: <200705091500.43803.opensource@till.name> <1178722630.5869.69.camel@localhost.localdomain> Message-ID: <4641E2B6.6020704@hhs.nl> Toshio Kuratomi wrote: > That sounds good. The ocaml guidelines that are currently in draft form > use a prefix of ocaml- as well. > Talking about those, apologies I couldn't make it to the FPC meeting, any progress / discussion on this I missed? Regards, Hans From Axel.Thimm at ATrpms.net Wed May 9 15:53:41 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 May 2007 17:53:41 +0200 Subject: Packaging Haskell libraries In-Reply-To: <4641E2B6.6020704@hhs.nl> References: <200705091500.43803.opensource@till.name> <1178722630.5869.69.camel@localhost.localdomain> <4641E2B6.6020704@hhs.nl> Message-ID: <20070509155341.GA1606@neu.nirvana> On Wed, May 09, 2007 at 05:03:18PM +0200, Hans de Goede wrote: > Toshio Kuratomi wrote: > >That sounds good. The ocaml guidelines that are currently in draft form > >use a prefix of ocaml- as well. > > > > Talking about those, > > apologies I couldn't make it to the FPC meeting, any progress / discussion > on this I missed? Hm, they haven't made it to the agenda yet, I guess the authors are still tuning them. We didn't talk about ocaml in the last meeting - it was rather thin anyway with several people on route to the RH summit. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Wed May 9 16:08:09 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 09 May 2007 09:08:09 -0700 Subject: Packaging Haskell libraries In-Reply-To: <20070509155341.GA1606@neu.nirvana> References: <200705091500.43803.opensource@till.name> <1178722630.5869.69.camel@localhost.localdomain> <4641E2B6.6020704@hhs.nl> <20070509155341.GA1606@neu.nirvana> Message-ID: <1178726889.5869.71.camel@localhost.localdomain> On Wed, 2007-05-09 at 17:53 +0200, Axel Thimm wrote: > On Wed, May 09, 2007 at 05:03:18PM +0200, Hans de Goede wrote: > > Toshio Kuratomi wrote: > > >That sounds good. The ocaml guidelines that are currently in draft form > > >use a prefix of ocaml- as well. > > > > > > > Talking about those, > > > > apologies I couldn't make it to the FPC meeting, any progress / discussion > > on this I missed? > > Hm, they haven't made it to the agenda yet, I guess the authors are > still tuning them. We didn't talk about ocaml in the last meeting - it > was rather thin anyway with several people on route to the RH summit. Now added to the agenda. Thanks Hans. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed May 9 16:56:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 May 2007 09:56:43 -0700 Subject: Buildsystem Outage In-Reply-To: <463F6E33.1040304@redhat.com> References: <463F6E33.1040304@redhat.com> Message-ID: <200705090956.43695.jkeating@redhat.com> On Monday 07 May 2007 11:21:39 Mike McGrath wrote: > We're upgrading some hardware (filers) on Wed, 10:30-12:30 EST. ?Sorry > for any inconvenience. Can you be specific as to what parts of the infrastructure will be effected? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed May 9 17:15:55 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 09 May 2007 12:15:55 -0500 Subject: Buildsystem Outage (UPDATE) In-Reply-To: <200705090956.43695.jkeating@redhat.com> References: <463F6E33.1040304@redhat.com> <200705090956.43695.jkeating@redhat.com> Message-ID: <464201CB.2030701@redhat.com> Jesse Keating wrote: > On Monday 07 May 2007 11:21:39 Mike McGrath wrote: > >> We're upgrading some hardware (filers) on Wed, 10:30-12:30 EST. Sorry >> for any inconvenience. >> > > Can you be specific as to what parts of the infrastructure will be effected? > First an update. The hardware did not arrive on time so Stacy was unable to get started when we planned. As such the outage will start later (probably in the next 15 minutes) and end later. Sorry for any inconvenience, I'll try to send specific times as soon as I get them. As far as parts of the infrastructure that will be effected: Anything related to builds. Both plague and koji Some public mirrors may see increased latency as we redirect to the secondary public mirror things unaffected: CVS Web Apps Torrent -Mike From limb at jcomserv.net Wed May 9 17:22:27 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 9 May 2007 12:22:27 -0500 (CDT) Subject: Buildsystem Outage (UPDATE) In-Reply-To: <464201CB.2030701@redhat.com> References: <463F6E33.1040304@redhat.com> <200705090956.43695.jkeating@redhat.com> <464201CB.2030701@redhat.com> Message-ID: <18013.65.192.24.190.1178731347.squirrel@mail.jcomserv.net> Ah. So the delay in CVS request fulfillment is most likely due to Summit rather than infrastructure? :) > Jesse Keating wrote: >> On Monday 07 May 2007 11:21:39 Mike McGrath wrote: >> >>> We're upgrading some hardware (filers) on Wed, 10:30-12:30 EST. Sorry >>> for any inconvenience. >>> >> >> Can you be specific as to what parts of the infrastructure will be >> effected? >> > > First an update. The hardware did not arrive on time so Stacy was > unable to get started when we planned. As such the outage will start > later (probably in the next 15 minutes) and end later. Sorry for any > inconvenience, I'll try to send specific times as soon as I get them. > > As far as parts of the infrastructure that will be effected: > Anything related to builds. Both plague and koji > Some public mirrors may see increased latency as we redirect to the > secondary public mirror > > things unaffected: > CVS > Web Apps > Torrent > > -Mike > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From tibbs at math.uh.edu Wed May 9 17:26:12 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 May 2007 12:26:12 -0500 Subject: Summary of the 2007-05-08 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-05-08 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070508 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Two PHP proposals: http://fedoraproject.org/wiki/PackagingDrafts/PHP (the first two items only: PECL Extensions and Versioned BuildRequires in Macros Section) * Ruby Gems guidelines: http://fedoraproject.org/wiki/PackagingDrafts/RubyGems These should be written into the guidelines soon if this hasn't already been done by the time you read this. No quorum this week due to the Red Hat summit, so no new items are presented to FESCo for ratification. Misc business: * Some progress on http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups We will probably vote on this next week, so comments are appreciated. - J< From jwboyer at jdub.homelinux.org Wed May 9 17:33:21 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 12:33:21 -0500 Subject: Buildsystem Outage (UPDATE) In-Reply-To: <18013.65.192.24.190.1178731347.squirrel@mail.jcomserv.net> References: <463F6E33.1040304@redhat.com> <200705090956.43695.jkeating@redhat.com> <464201CB.2030701@redhat.com> <18013.65.192.24.190.1178731347.squirrel@mail.jcomserv.net> Message-ID: <1178732001.3086.47.camel@zod.rchland.ibm.com> On Wed, 2007-05-09 at 12:22 -0500, Jon Ciesla wrote: > Ah. So the delay in CVS request fulfillment is most likely due to Summit > rather than infrastructure? :) Likely, yes. And I personally haven't had a chance to do any. I'll try and get some done this evening. josh From limb at jcomserv.net Wed May 9 17:38:09 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 9 May 2007 12:38:09 -0500 (CDT) Subject: Buildsystem Outage (UPDATE) In-Reply-To: <1178732001.3086.47.camel@zod.rchland.ibm.com> References: <463F6E33.1040304@redhat.com> <200705090956.43695.jkeating@redhat.com> <464201CB.2030701@redhat.com> <18013.65.192.24.190.1178731347.squirrel@mail.jcomserv.net> <1178732001.3086.47.camel@zod.rchland.ibm.com> Message-ID: <19193.65.192.24.190.1178732289.squirrel@mail.jcomserv.net> I assumed. That's why I'd not nagged before. Many thanks. > On Wed, 2007-05-09 at 12:22 -0500, Jon Ciesla wrote: >> Ah. So the delay in CVS request fulfillment is most likely due to Summit >> rather than infrastructure? :) > > Likely, yes. And I personally haven't had a chance to do any. I'll try > and get some done this evening. > > josh > -- novus ordo absurdum From j.w.r.degoede at hhs.nl Wed May 9 18:44:55 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 May 2007 20:44:55 +0200 Subject: Summary of the 2007-05-08 Packaging Committee meeting In-Reply-To: References: Message-ID: <464216A7.3020401@hhs.nl> Jason L Tibbitts III wrote: > Misc business: > * Some progress on > http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups > We will probably vote on this next week, so comments are > appreciated. > I see this only talks about adding users + groups. In the Games SIG we sometimes have packages which only add a group, for sgid use for a shared scoreboard file. Rationale: most games use sgid games for this, and have been audited / modified so that someone attacking the game can only corrupt the games own files and not files of other games. This is still a potential security issue on a multi user system, but a very small issue IMHO. Some games however for various reasons can not be modified so that we can guarantee someone attacking the game will only be able to modify that games files. To give these games the same containement as the other games, we give there shared files their own group and make the game sgid to this group. Long story short, could one or two lines about only adding a group and not a user be added? Regards, Hans From bos at serpentine.com Wed May 9 18:32:51 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 09 May 2007 11:32:51 -0700 Subject: Packaging Haskell libraries In-Reply-To: <200705091500.43803.opensource@till.name> References: <200705091500.43803.opensource@till.name> Message-ID: <464213D3.7080507@serpentine.com> Hi, Till - > Is packaging them as > > haskell-X11 > haskell-X11-extras > haskell-mtl > > ok? No, I'm afraid not. There are already two Haskell implementations available in Extras, hugs and ghc. Additionally, the Haskell compilers make no attempt to preserve ABI compatibility across releases. For these reasons, the tiny handful of existing Haskell packages that are already packaged are prefixed with the name and version of the compiler they're built against, not with a simple "haskell-". For example, the Gtk2Hs package is named ghc66-gtk2hs. This is a pretty reasonable naming scheme. Finally, packaging Haskell libraries is a subtle business, because a Haskell compiler has its own package manager that needs to be treated properly, or you'll have a terrible mess on your hands where RPM and your Haskell implementation have different notions as to what's installed. In particular with the X11 and mtl packages, older versions of those are already shipped with ghc itself. You should take a look at my cabal-rpm tool, which generates a clean RPM spec file for Haskell packages that are packaged with the Cabal system: http://darcs.serpentine.com/cabal-rpm/ Jens Petersen has been talking about establishing a Haskell SIG, which would be a good place to air issues like these before bringing them up for wider discussion. References: <200705091500.43803.opensource@till.name> <464213D3.7080507@serpentine.com> Message-ID: >>>>> "BO" == Bryan O'Sullivan writes: BO> Finally, packaging Haskell libraries is a subtle business, because BO> a Haskell compiler has its own package manager that needs to be BO> treated properly, or you'll have a terrible mess on your hands BO> where RPM and your Haskell implementation have different notions BO> as to what's installed. Oh, goody, my theory that all languages eventually grow their own package manager still holds. This kind of complexity means that we really need firm and clear guidelines laid down before we start accepting any packages. Hopefully someone can cook up a draft that FPC can go over. - J< From tibbs at math.uh.edu Wed May 9 19:05:52 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 May 2007 14:05:52 -0500 Subject: Summary of the 2007-05-08 Packaging Committee meeting In-Reply-To: <464216A7.3020401@hhs.nl> References: <464216A7.3020401@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> Long story short, could one or two lines about only adding a HdG> group and not a user be added? I've tacked your request onto the draft so that Ville don't miss it. - J< From bos at serpentine.com Wed May 9 19:11:54 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 09 May 2007 12:11:54 -0700 Subject: Packaging Haskell libraries In-Reply-To: References: <200705091500.43803.opensource@till.name> <464213D3.7080507@serpentine.com> Message-ID: <46421CFA.60909@serpentine.com> Jason L Tibbitts III wrote: > This kind of complexity means that we really need firm and clear > guidelines laid down before we start accepting any packages. Yes. Jens Petersen's packaged most of the existing Haskell stuff, and I've just gotten started. I'll see about cooking up a SIG and packaging guidelines and blah blah blah. References: <1178673883.3175.109.camel@vader.jdub.homelinux.org> Message-ID: <464220AD.1000905@fedoraproject.org> Josh Boyer wrote: > The bulk of the Core/Extras merge has now been finished, and the Release > Engineering team has been working hard to get things back in shape for > the final F7 release. However, due to the massive nature of this > undertaking, we are not coming back online as fast as we had hoped. > > We do not have a rawhide repository available as of yet, and the release > and QA teams are not comfortable going into deep freeze at this point. > During the Release team meeting yesterday, it was decided to slip the > deep freeze date by a week at least. This will also slip the final > release of Fedora 7 by at least a week. > > Slipping a week will allow more time for the merge tree to materialize > and stabilize. Maintainers will also have more time to adjust to the > new processes involved as a result of the merge. We will also have more > time to evaluate the blocking bugs that are currently open in Bugzilla. > > While this slip is unfortunate, it is also in the best interest for the > quality of the release. Please bear with us as we strive to make this > the best release of Fedora to date! Please update http://fedoraproject.org/wiki/Releases/7/Schedule Rahul From jwboyer at jdub.homelinux.org Wed May 9 19:36:40 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 14:36:40 -0500 Subject: [Announcement] Fedora 7 Deep Freeze/GA release schedule change In-Reply-To: <464220AD.1000905@fedoraproject.org> References: <1178673883.3175.109.camel@vader.jdub.homelinux.org> <464220AD.1000905@fedoraproject.org> Message-ID: <1178739400.3086.75.camel@zod.rchland.ibm.com> On Thu, 2007-05-10 at 00:57 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > The bulk of the Core/Extras merge has now been finished, and the Release > > Engineering team has been working hard to get things back in shape for > > the final F7 release. However, due to the massive nature of this > > undertaking, we are not coming back online as fast as we had hoped. > > > > We do not have a rawhide repository available as of yet, and the release > > and QA teams are not comfortable going into deep freeze at this point. > > During the Release team meeting yesterday, it was decided to slip the > > deep freeze date by a week at least. This will also slip the final > > release of Fedora 7 by at least a week. > > > > Slipping a week will allow more time for the merge tree to materialize > > and stabilize. Maintainers will also have more time to adjust to the > > new processes involved as a result of the merge. We will also have more > > time to evaluate the blocking bugs that are currently open in Bugzilla. > > > > While this slip is unfortunate, it is also in the best interest for the > > quality of the release. Please bear with us as we strive to make this > > the best release of Fedora to date! > > Please update http://fedoraproject.org/wiki/Releases/7/Schedule Done for now. I will update it with the actual dates as soon as we have something more firm that "at least one week slip". Thanks for pointing this out. josh From Axel.Thimm at ATrpms.net Wed May 9 20:04:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 May 2007 22:04:17 +0200 Subject: Post-merge howto and FAQ In-Reply-To: <1178593238.25550.10.camel@vader.jdub.homelinux.org> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> Message-ID: <20070509200417.GB16616@neu.nirvana> Hi, On Mon, May 07, 2007 at 10:00:38PM -0500, Josh Boyer wrote: > Due to popular demand, I sat down and wrote up a brief howto for > handling packages in the merged world. Given that I'm almost guaranteed > to have not answered all the questions, it's living under: > > http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO > > for the moment. Hopefully it will give the package maintainers a high > level overview of what to do and how to do it. Feel free to ask > questions and I (or others) will try to address them. > > Once we get a decent enough document in place, the content can be > generalized and we'll update the main packaging documents with the > appropriate information. Thanks, Josh, I have a question (of which I don't really know the answer) for the FAQ: After Q: What happens to the packages tagged with dist-fc7 but not f7-final ... Q: Will I need to rebuilt my packages when Fedora 8 development begins? ... my question would be: Q: Will packages in dist-fc7 that were inherited into dist-fc8 appear in F8's rawhide? I _assume_ the answer is A: Yes, rawhide is only limited to f7-final until F7 goes gold. After that rawhide will be rebased on dist-fc8, so any package that was in dist-fc7 and not in f7-final will reappear in rawhide. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed May 9 20:02:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 09 May 2007 15:02:00 -0500 Subject: Post-merge howto and FAQ In-Reply-To: <20070509200417.GB16616@neu.nirvana> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509200417.GB16616@neu.nirvana> Message-ID: <1178740920.3086.84.camel@zod.rchland.ibm.com> On Wed, 2007-05-09 at 22:04 +0200, Axel Thimm wrote: > Hi, > > On Mon, May 07, 2007 at 10:00:38PM -0500, Josh Boyer wrote: > > Due to popular demand, I sat down and wrote up a brief howto for > > handling packages in the merged world. Given that I'm almost guaranteed > > to have not answered all the questions, it's living under: > > > > http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO > > > > for the moment. Hopefully it will give the package maintainers a high > > level overview of what to do and how to do it. Feel free to ask > > questions and I (or others) will try to address them. > > > > Once we get a decent enough document in place, the content can be > > generalized and we'll update the main packaging documents with the > > appropriate information. > > Thanks, Josh, I have a question (of which I don't really know the > answer) for the FAQ: > > After > > Q: What happens to the packages tagged with dist-fc7 but not f7-final > ... > Q: Will I need to rebuilt my packages when Fedora 8 development > begins? > ... > > my question would be: > > Q: Will packages in dist-fc7 that were inherited into dist-fc8 appear > in F8's rawhide? Good question. > I _assume_ the answer is > > A: Yes, rawhide is only limited to f7-final until F7 goes gold. After > that rawhide will be rebased on dist-fc8, so any package that was > in dist-fc7 and not in f7-final will reappear in rawhide. And I believe you are correct with your answer. Jesse would know for sure, but he's off Summitting. I'll ask to be sure. josh From Axel.Thimm at ATrpms.net Wed May 9 20:13:40 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 9 May 2007 22:13:40 +0200 Subject: Post-merge howto and FAQ In-Reply-To: <200705080933.12493.opensource@till.name> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <200705080933.12493.opensource@till.name> Message-ID: <20070509201340.GC16616@neu.nirvana> Hi, On Tue, May 08, 2007 at 09:33:06AM +0200, Till Maas wrote: > as far as I understand the new process, there should be a big fat > warning given to Extras maintainers not to update their FE 6 and 5 > packages (except for adding an integer after the dist-tag) Well, that doesn't help in the case of a version bump which is the most often package update class in Fedora (compared to updates to the specfile changes or added/changed patches which keep the version invariant). I'd say try to do both in parallel with priority on F7, so it has a chance to catch up. If you *can* wait for < F7 the better, but F7 shouldn't become a bottleneck for FC6/FE6 maintenance. The policy is anyway that F7 doesn't really need to rebuild FC6 packages, unless you have a Real Good Reason. Personally I'm not a believer of this policy, but maybe you are, so you don't even have to think about upgrade paths :) (Thinking about it this is why this policy was set up ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed May 9 20:11:21 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 May 2007 16:11:21 -0400 Subject: Post-merge howto and FAQ In-Reply-To: <20070509200417.GB16616@neu.nirvana> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509200417.GB16616@neu.nirvana> Message-ID: <20070509201121.GA5621@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > I _assume_ the answer is > > A: Yes, rawhide is only limited to f7-final until F7 goes gold. After > that rawhide will be rebased on dist-fc8, so any package that was > in dist-fc7 and not in f7-final will reappear in rawhide. Correct. Bill From pertusus at free.fr Wed May 9 20:47:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 9 May 2007 22:47:11 +0200 Subject: where to report koji issues? Message-ID: <20070509204711.GA2831@free.fr> Hello, I have an issue with the koji build of gnash (task 5497). Where should I report it? I don't see anything on the koji website itself. In case it is the place to report it, I got .... 0 free 2 open 4 done 0 failed 5497 build (dist-fc7, devel:gnash-0_7_2-2_fc7): open (xenbuilder4.fedora.phx.redhat.com) -> free : (-1, 'Unexpected EOF') make: *** [koji] Erreur 1 and now the build doesn't seems to complete on ppc64. -- Pat From jkeating at redhat.com Wed May 9 20:57:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 May 2007 13:57:27 -0700 Subject: where to report koji issues? In-Reply-To: <20070509204711.GA2831@free.fr> References: <20070509204711.GA2831@free.fr> Message-ID: <200705091357.27765.jkeating@redhat.com> On Wednesday 09 May 2007 13:47:11 Patrice Dumas wrote: > Hello, > > I have an issue with the koji build of gnash (task 5497). Where should > I report it? I don't see anything on the koji website itself. > > In case it is the place to report it, I got > > .... > ? 0 free ?2 open ?4 done ?0 failed > 5497 build (dist-fc7, devel:gnash-0_7_2-2_fc7): open > (xenbuilder4.fedora.phx.redhat.com) -> free > : (-1, 'Unexpected EOF') > make: *** [koji] Erreur 1 > > and now the build doesn't seems to complete on ppc64. Your tail of the task timed out, the task continued. I looked at http://koji.fedoraproject.org/koji/builds and saw the gnash build still going http://koji.fedoraproject.org/koji/buildinfo?buildID=6414 You could watch it again on the cli with 'koji watch-task 6414' -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed May 9 21:05:05 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 09 May 2007 17:05:05 -0400 Subject: Plan for tomorrows (20070510) FESCO meeting Message-ID: <1178744705.5807.6.camel@lincoln> Hi, I guessing the turnout for tomorrow's meeting will be pretty light, due to this week's Red Hat Summit. Anyway, please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- Policies that need updating for merge? -- http://fedoraproject.org/wiki/PackageMaintainers/Policy /topic FESCO-Meeting -- MISC -- EPEL Reporting - https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- EPEL? /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed May 9 20:57:53 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 9 May 2007 22:57:53 +0200 Subject: where to report koji issues? In-Reply-To: <200705091357.27765.jkeating@redhat.com> References: <20070509204711.GA2831@free.fr> <200705091357.27765.jkeating@redhat.com> Message-ID: <20070509205753.GB2831@free.fr> On Wed, May 09, 2007 at 01:57:27PM -0700, Jesse Keating wrote: > > Your tail of the task timed out, the task continued. I looked at > http://koji.fedoraproject.org/koji/builds and saw the gnash build still going > http://koji.fedoraproject.org/koji/buildinfo?buildID=6414 > > You could watch it again on the cli with 'koji watch-task 6414' Ok, it looked like it was hanging, but I'll wait some more time. -- Pat From mmcgrath at redhat.com Wed May 9 21:10:34 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 09 May 2007 16:10:34 -0500 Subject: where to report koji issues? In-Reply-To: <20070509204711.GA2831@free.fr> References: <20070509204711.GA2831@free.fr> Message-ID: <464238CA.1060603@redhat.com> Patrice Dumas wrote: > Hello, > > I have an issue with the koji build of gnash (task 5497). Where should > I report it? I don't see anything on the koji website itself. > Report it to the ticketing system (https://admin.fedoraproject.org/tickets/) Or, even better, come by #fedora-admin on irc.freenode.net -Mike From pertusus at free.fr Wed May 9 22:14:58 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 May 2007 00:14:58 +0200 Subject: orphaning packages in a new world Message-ID: <20070509221458.GA2910@free.fr> Hello, It seems to me that http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages is not up to date. For example it says 2. Edit owners.list in Fedora Package CVS and set the initialowner field of your package to extras-orphan[AT]fedoraproject.org e-mail address (substitute the [AT] appropriately). And similar regarding how to unorphan package. There is also a reference to https://bugzilla.redhat.com/bugzilla/describecomponents.cgi?product=Fedora%20Extras which seems to be obsolete to me. Does anybody knows what replace that page? Also there is no mention of dead.package (or link to http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife from http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages#head-b09f62db1ef61a68d8c44a72abf5fbd2e6a835fe Shouldn't it be something along 'if nobody has claimed ownership of your package you should follow http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife for the devel branch.' -- Pat From opensource at till.name Wed May 9 23:50:48 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 01:50:48 +0200 Subject: Packaging Haskell libraries In-Reply-To: <464213D3.7080507@serpentine.com> References: <200705091500.43803.opensource@till.name> <464213D3.7080507@serpentine.com> Message-ID: <200705100150.51528.opensource@till.name> On Mi Mai 9 2007, Bryan O'Sullivan wrote: > For these reasons, the tiny handful of existing Haskell packages that > are already packaged are prefixed with the name and version of the > compiler they're built against, not with a simple "haskell-". For > example, the Gtk2Hs package is named ghc66-gtk2hs. This is a pretty > reasonable naming scheme. There seems to be also "ghc-gtk2hs" and only "gtk2hs-doc" without any ghc prefix in Fedora Extras 6. > Finally, packaging Haskell libraries is a subtle business, because a > Haskell compiler has its own package manager that needs to be treated > properly, or you'll have a terrible mess on your hands where RPM and > your Haskell implementation have different notions as to what's > installed. In particular with the X11 and mtl packages, older versions > of those are already shipped with ghc itself. Can I use the hugs98-x11 with ghc or need all libraries used by ghc be compiled by ghc, too? Or is this a complete different package? > You should take a look at my cabal-rpm tool, which generates a clean RPM > spec file for Haskell packages that are packaged with the Cabal system: > > http://darcs.serpentine.com/cabal-rpm/ Thanks, I will take a look at it when I will try to build xmonad and its dependencies. But knowing these new obstacles, my motivation just became less. Regards, Till From bos at serpentine.com Thu May 10 00:06:36 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 09 May 2007 17:06:36 -0700 Subject: Packaging Haskell libraries In-Reply-To: <200705100150.51528.opensource@till.name> References: <200705091500.43803.opensource@till.name> <464213D3.7080507@serpentine.com> <200705100150.51528.opensource@till.name> Message-ID: <4642620C.5050601@serpentine.com> Till Maas wrote: > There seems to be also "ghc-gtk2hs" and only "gtk2hs-doc" without any ghc > prefix in Fedora Extras 6. Yep. The ghc-gtk2hs package is empty; I don't know what purpose it is supposed to serve. It's understandable that the doc package would be implementation independent :-) > Can I use the hugs98-x11 with ghc or need all libraries used by ghc be > compiled by ghc, too? Or is this a complete different package? Hugs and GHC are not binary compatible, so they need duplicates of every library package. > Thanks, I will take a look at it when I will try to build xmonad and its > dependencies. But knowing these new obstacles, my motivation just became > less. FWIW, it took me about 5 minutes to build xmonad using cabal-rpm. References: <463F6E33.1040304@redhat.com> <200705090956.43695.jkeating@redhat.com> <464201CB.2030701@redhat.com> Message-ID: <464263A3.1020308@redhat.com> Mike McGrath wrote: The outage should be over now. A few plague based jobs may need to be re-queued. Koji has been up for a while (parts of this outage had a longer impact on the plague stuff) If you're having any build problems from this point forward let someone know. -Mike From opensource at till.name Thu May 10 00:40:58 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 02:40:58 +0200 Subject: Packaging Haskell libraries In-Reply-To: <4642620C.5050601@serpentine.com> References: <200705091500.43803.opensource@till.name> <200705100150.51528.opensource@till.name> <4642620C.5050601@serpentine.com> Message-ID: <200705100240.59934.opensource@till.name> On Do Mai 10 2007, Bryan O'Sullivan wrote: > Yep. The ghc-gtk2hs package is empty; I don't know what purpose it is > supposed to serve. Thinking about it, maybe it is just for convenience, when it depends on the latest gtk2hs ghc package, one can install it to get always the latest. Hm, there is a 1.3 MB ghc and a 31 MB ghc66 package, this is strange. > It's understandable that the doc package would be > implementation independent :-) Oh, this is true, but I would expect the documentation in a -doc subpackage, maybe a "virtual" package like the ghc-gtk2hs package would be better. I do not know, whether or not a "Provide"-tag would be fine, too. > FWIW, it took me about 5 minutes to build xmonad using cabal-rpm. Does cabal-rpm output rpms or srpms / specs? Can you provide me the specs / srpms? It will take me a lot longer just to understand, how to use xmonad. Do I have to install it with "Setup.lhs"? Regards, Till From opensource at till.name Thu May 10 00:43:58 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 02:43:58 +0200 Subject: Summary of the 2007-05-08 Packaging Committee meeting In-Reply-To: <464216A7.3020401@hhs.nl> References: <464216A7.3020401@hhs.nl> Message-ID: <200705100244.01729.opensource@till.name> On Mi Mai 9 2007, Hans de Goede wrote: > Long story short, could one or two lines about only adding a group and not > a user be added? This is useful for other purposes, too. E.g. for kqemu, when it ever gets into Fedora, or some time for VirtualBox, which both use a device in /dev and only a special group of users should be able to use it. Regards, Till From opensource at till.name Thu May 10 00:50:29 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 02:50:29 +0200 Subject: Post-merge howto and FAQ In-Reply-To: <20070509201340.GC16616@neu.nirvana> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <200705080933.12493.opensource@till.name> <20070509201340.GC16616@neu.nirvana> Message-ID: <200705100250.31501.opensource@till.name> On Mi Mai 9 2007, Axel Thimm wrote: > The policy is anyway that F7 doesn't really need to rebuild FC6 > packages, unless you have a Real Good Reason. Personally I'm not a > believer of this policy, but maybe you are, so you don't even have to > think about upgrade paths :) > (Thinking about it this is why this policy was set up ;) I do not understand what you are writing there, especially what upgrade paths have to do with the rebuilding of packages at least once in the devel branch. Regards, Till From petersen at redhat.com Thu May 10 03:29:32 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 10 May 2007 13:29:32 +1000 Subject: Packaging Haskell libraries In-Reply-To: <200705100240.59934.opensource@till.name> References: <200705091500.43803.opensource@till.name> <200705100150.51528.opensource@till.name> <4642620C.5050601@serpentine.com> <200705100240.59934.opensource@till.name> Message-ID: <4642919C.4030903@redhat.com> Till Maas ????????: > On Do Mai 10 2007, Bryan O'Sullivan wrote: >> Yep. The ghc-gtk2hs package is empty; I don't know what purpose it is >> supposed to serve. > > Thinking about it, maybe it is just for convenience, when it depends on the > latest gtk2hs ghc package, one can install it to get always the latest. That's right. > Hm, there is a 1.3 MB ghc and a 31 MB ghc66 package, this is strange. ghc contains some of the utilities that are not really ghc version dependent and unversioned symlinks to the versioned compiler programs. The main compiler and libraries are all in ghc66. Bryan is going to update ghc to 6.6.1 soon btw. > Oh, this is true, but I would expect the documentation in a -doc subpackage It is. :) There are gtk2hs-doc and ghc-doc. Jens From petersen at redhat.com Thu May 10 03:36:12 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 10 May 2007 13:36:12 +1000 Subject: Packaging Haskell libraries In-Reply-To: <200705091500.43803.opensource@till.name> References: <200705091500.43803.opensource@till.name> Message-ID: <4642932C.2020904@redhat.com> Till Maas ????????: > I want to test a new window manager (http://xmonad.org/) and maybe package it > for Fedora. Cool. :) > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-1.2 Not sure what the version is in ghc-6.6.1. 6.6 has 1.1. > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mtl-1.0 This is already in ghc-6.6. Jens From petersen at redhat.com Thu May 10 03:41:11 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 10 May 2007 13:41:11 +1000 Subject: Packaging Haskell libraries In-Reply-To: References: <200705091500.43803.opensource@till.name> <464213D3.7080507@serpentine.com> Message-ID: <46429457.7000506@redhat.com> Jason L Tibbitts III ????????: > This kind of complexity means that we really need firm and clear > guidelines laid down before we start accepting any packages. > Hopefully someone can cook up a draft that FPC can go over. That is right. gtk2hs was the first testcase of the Haskell library being added to Fedora based on all the earlier packaging work at . I would be very happy to have guidelines for packaging haskell libraries written down. :) Jens From petersen at redhat.com Thu May 10 03:50:12 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 10 May 2007 13:50:12 +1000 Subject: Packaging Haskell libraries In-Reply-To: <200705100150.51528.opensource@till.name> References: <200705091500.43803.opensource@till.name> <464213D3.7080507@serpentine.com> <200705100150.51528.opensource@till.name> Message-ID: <46429674.2080705@redhat.com> Till Maas ????????: > Can I use the hugs98-x11 with ghc or need all libraries used by ghc be > compiled by ghc, too? Or is this a complete different package? hugs98 and ghc already both come with the X11 library. But for any new haskell library that works with both ghc and hugs being added to fedora, we should make both hugs98 and ghc subpackages for it. It would be good if our proposed Haskell SIG documented all this. Jens From Axel.Thimm at ATrpms.net Thu May 10 05:46:45 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 May 2007 07:46:45 +0200 Subject: Post-merge howto and FAQ In-Reply-To: <200705100250.31501.opensource@till.name> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <200705080933.12493.opensource@till.name> <20070509201340.GC16616@neu.nirvana> <200705100250.31501.opensource@till.name> Message-ID: <20070510054645.GA30989@neu.nirvana> On Thu, May 10, 2007 at 02:50:29AM +0200, Till Maas wrote: > On Mi Mai 9 2007, Axel Thimm wrote: > > The policy is anyway that F7 doesn't really need to rebuild FC6 > > packages, unless you have a Real Good Reason. Personally I'm not a > > believer of this policy, but maybe you are, so you don't even have to > > think about upgrade paths :) > > (Thinking about it this is why this policy was set up ;) > > I do not understand what you are writing there, especially what upgrade paths > have to do with the rebuilding of packages at least once in the devel branch. If a package is not rebuilt from FC6 to F7 (or F7 and F8 etc) then there is no need to think about upgrade paths, they are trivial, e.g. no upgrade is needed at all. And the policy of rebuilding packages at least once does (sadly) not apply for F7, it will hopefully be picked again for F8, let's see. So with the current policy in place: If your package does not have a Real Good Reason to be rebuilt for F7 wrt to FC6 then you are discouraged to do so, and therefore you can possibly even get away with a simple cp op and never get into the problem of F7 < FC6 and having to rebuild for F7. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Thu May 10 08:32:27 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 10:32:27 +0200 Subject: Post-merge howto and FAQ In-Reply-To: <20070510054645.GA30989@neu.nirvana> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <200705100250.31501.opensource@till.name> <20070510054645.GA30989@neu.nirvana> Message-ID: <200705101032.29111.opensource@till.name> On Do Mai 10 2007, Axel Thimm wrote: > If a package is not rebuilt from FC6 to F7 (or F7 and F8 etc) then > there is no need to think about upgrade paths, they are trivial, > e.g. no upgrade is needed at all. But when I update a package now in FC6, the package in F7 will be older. Sure, if one does not change anything, i.e. not updating a FC6 package in the FC6 lifetime, that there will be no problems with the upgrade path. > discouraged to do so, and therefore you can possibly even get away > with a simple cp op and never get into the problem of F7 < FC6 and > having to rebuild for F7. What "cp op" are you talking about? Afaik there will be only a copy of some packages in "devel" to F7 (the packages, that are tagged f7-final). Regards, Till From petersen at redhat.com Thu May 10 08:38:28 2007 From: petersen at redhat.com (Jens Petersen) Date: Thu, 10 May 2007 18:38:28 +1000 Subject: Packaging Haskell libraries In-Reply-To: <464213D3.7080507@serpentine.com> References: <200705091500.43803.opensource@till.name> <464213D3.7080507@serpentine.com> Message-ID: <4642DA04.7060701@redhat.com> Bryan O'Sullivan ????????: > Jens Petersen has been talking about establishing a Haskell SIG, which > would be a good place to air issues like these before bringing them up > for wider discussion. Yes, it has been on my todo list for a while. I just wrote an initial . Feel free to join in, edit and add stuff. :) Jens From Christian.Iseli at licr.org Thu May 10 08:51:47 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Thu, 10 May 2007 10:51:47 +0200 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <1178744705.5807.6.camel@lincoln> References: <1178744705.5807.6.camel@lincoln> Message-ID: <20070510105147.47f4af4b@ludwig-alpha.unil.ch> Dear all, On Wed, 09 May 2007 17:05:05 -0400, Brian Pepple wrote: > Anyway, please find below the list of > topics that are likely to come up in the next FESCo meeting that is > scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on > irc.freenode.org: I won't be able to attend: I have voluntary firefighter training that I need to attend... In case the zope thing comes up again, here is my current view: - I'm not in favor of a compat-python2.4 package: o python maintainer doesn't want it o not in line with a bleeding edge distro o does not encourage other packages to update to newer version - I could agree to a runzope package, or maybe even better a zope-runtime sub-package Cheers, C From bugs.michael at gmx.net Thu May 10 09:32:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 10 May 2007 11:32:22 +0200 Subject: orphaning packages in a new world In-Reply-To: <20070509221458.GA2910@free.fr> References: <20070509221458.GA2910@free.fr> Message-ID: <20070510113222.5d6e747e.bugs.michael@gmx.net> On Thu, 10 May 2007 00:14:58 +0200, Patrice Dumas wrote: > Hello, > > It seems to me that > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > is not up to date. Correct. I've announced in February, that I won't take care of the page contents any longer because of several reasons. From Axel.Thimm at ATrpms.net Thu May 10 09:00:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 May 2007 11:00:57 +0200 Subject: Post-merge howto and FAQ In-Reply-To: <200705101032.29111.opensource@till.name> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <200705100250.31501.opensource@till.name> <20070510054645.GA30989@neu.nirvana> <200705101032.29111.opensource@till.name> Message-ID: <20070510090057.GA14236@neu.nirvana> On Thu, May 10, 2007 at 10:32:27AM +0200, Till Maas wrote: > On Do Mai 10 2007, Axel Thimm wrote: > > > If a package is not rebuilt from FC6 to F7 (or F7 and F8 etc) then > > there is no need to think about upgrade paths, they are trivial, > > e.g. no upgrade is needed at all. > > But when I update a package now in FC6, the package in F7 will be older. Sure, > if one does not change anything, i.e. not updating a FC6 package in the FC6 > lifetime, that there will be no problems with the upgrade path. If the package is indeed not worth to rebuild it, then there is no upgrade neccessary on a client's system going from FC6 to F7, and F7 can get a copy of the package (no rebuild) at some later time, no need to wait for an F7 rebuild in deep freeze to proceed with fixing FC6 bits. > > discouraged to do so, and therefore you can possibly even get away > > with a simple cp op and never get into the problem of F7 < FC6 and > > having to rebuild for F7. > > What "cp op" are you talking about? Afaik there will be only a copy of some > packages in "devel" to F7 (the packages, that are tagged f7-final). Packages that are the same across dists can be simply copied over. This is what automagically happens at each new release cycle, and what you can otherwise ask for. This usually happens for packages that are known to "never" [1] change across releases, e.g. data packages, firmwares, fonts. But why not for this case, too, if the conventional push to F7 is more painful and a rebuilt not really required? Note: I'm a strong proponent of rebuilding everything for F7 (other then data files, firmware and such trivial non-rebuildable stuff), so having me explain how to not rebuild your packages is contrary to my religion. But my religion != F7 policy, and the latter asks you to not rebuild w/o a Damned Good Reason. Please don't ask me to justify non rebuilding further, I can't. ;) [1] "never" is relative as even firmwares get installed under different paths on different releases, but it's as close to "never" as it gets. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexl at users.sourceforge.net Thu May 10 11:25:32 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 10 May 2007 04:25:32 -0700 Subject: Post-merge howto and FAQ In-Reply-To: <20070509201121.GA5621@nostromo.devel.redhat.com> (Bill Nottingham's message of "Wed\, 9 May 2007 16\:11\:21 -0400") References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509200417.GB16616@neu.nirvana> <20070509201121.GA5621@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> Axel Thimm (Axel.Thimm at ATrpms.net) said: >> I _assume_ the answer is >> >> A: Yes, rawhide is only limited to f7-final until F7 goes >> gold. After that rawhide will be rebased on dist-fc8, so any >> package that was in dist-fc7 and not in f7-final will reappear in >> rawhide. BN> Correct. BN> Bill On the subject of tags now that we're merged, shouldn't all references to "fc" ("Fedora Core") be replaced with "f" ("Fedora"), i.e. dist-fc7 -> dist-f7 dist-fc8 -> dist-f8 and all new NVR for packages in f7 and later be of the form: foobar-1.2-3.f7 rather than: foobar-1.2-3.fc7 etc? It seems a little odd to be carrying forward the "fc" when Fedora Core will cease to exist as of F7. Alex From Axel.Thimm at ATrpms.net Thu May 10 11:45:19 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 May 2007 13:45:19 +0200 Subject: fc7 vs f7 (was: Post-merge howto and FAQ) In-Reply-To: References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509200417.GB16616@neu.nirvana> <20070509201121.GA5621@nostromo.devel.redhat.com> Message-ID: <20070510114519.GA19809@neu.nirvana> On Thu, May 10, 2007 at 04:25:32AM -0700, Alex Lancaster wrote: > On the subject of tags now that we're merged, shouldn't all references > to "fc" ("Fedora Core") be replaced with "f" ("Fedora"), i.e. > > dist-fc7 -> dist-f7 > dist-fc8 -> dist-f8 That would be possible. > and all new NVR for packages in f7 and later be of the form: > > foobar-1.2-3.f7 > > rather than: > > foobar-1.2-3.fc7 > > etc? It seems a little odd to be carrying forward the "fc" when > Fedora Core will cease to exist as of F7. The problem is that f7 < fc6 for rpm, so the newer packages would appear older to rpm. Once FC6 goes EOL (e.g. in about 8 months) we could introduce a new macro that would give f7/f8 etc disttags and every specfile that gets touched for all non-EOL dists would get %{?dist} -> %{?}, so that fcX tags would slowly fade away. But that would be at least another release cycle, e.g. by the summer 2008/F9. Or we could start right away and have fc6 -> f6 in that transitional scheme and hope that all packages will have been rebuilt by F8, so the fc tags would vanish by end of this year. But I think this is very low prio ATM. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Thu May 10 11:54:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 May 2007 13:54:36 +0200 Subject: fc7 vs f7 (was: Post-merge howto and FAQ) In-Reply-To: <20070510114519.GA19809@neu.nirvana> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509200417.GB16616@neu.nirvana> <20070509201121.GA5621@nostromo.devel.redhat.com> <20070510114519.GA19809@neu.nirvana> Message-ID: <20070510115436.GA2847@free.fr> On Thu, May 10, 2007 at 01:45:19PM +0200, Axel Thimm wrote: > > Or we could start right away and have fc6 -> f6 in that transitional > scheme and hope that all packages will have been rebuilt by F8, so the > fc tags would vanish by end of this year. But I think this is very low > prio ATM. I remember that we agreed to keep on using fc, with a new meaning, fedora collection. Isn't it the case? -- Pat From jwboyer at jdub.homelinux.org Thu May 10 12:00:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 10 May 2007 07:00:51 -0500 Subject: fc7 vs f7 (was: Post-merge howto and FAQ) In-Reply-To: <20070510115436.GA2847@free.fr> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509200417.GB16616@neu.nirvana> <20070509201121.GA5621@nostromo.devel.redhat.com> <20070510114519.GA19809@neu.nirvana> <20070510115436.GA2847@free.fr> Message-ID: <1178798451.22802.3.camel@zod.rchland.ibm.com> On Thu, 2007-05-10 at 13:54 +0200, Patrice Dumas wrote: > On Thu, May 10, 2007 at 01:45:19PM +0200, Axel Thimm wrote: > > > > Or we could start right away and have fc6 -> f6 in that transitional > > scheme and hope that all packages will have been rebuilt by F8, so the > > fc tags would vanish by end of this year. But I think this is very low > > prio ATM. > > I remember that we agreed to keep on using fc, with a new meaning, > fedora collection. Isn't it the case? Yes. It now stands for "fedora collection" as far as disttag goes. That being said, I think the koji tag for F8 will be dist-f8. The disttag isn't going to change though. josh From Axel.Thimm at ATrpms.net Thu May 10 12:45:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 10 May 2007 14:45:46 +0200 Subject: fc7 vs f7 (was: Post-merge howto and FAQ) In-Reply-To: <20070510115436.GA2847@free.fr> References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509200417.GB16616@neu.nirvana> <20070509201121.GA5621@nostromo.devel.redhat.com> <20070510114519.GA19809@neu.nirvana> <20070510115436.GA2847@free.fr> Message-ID: <20070510124546.GE19809@neu.nirvana> > I remember that we agreed to keep on using fc, with a new meaning, > fedora collection. Isn't it the case? Yes, but that's bending the names after the fact, it should be the other way around, especially for an (important) acronym that has been extensively used in another meaning over three years now. And some people consider using "Collection" in names of total spins etc, so it would become ambiguous what it means. Just let some time pass, and either people will not care and we will be using fc14 some day w/o anyone remembering what the c stand for, or people will nag enough that we will phase it into f14. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Thu May 10 11:58:56 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 10 May 2007 12:58:56 +0100 Subject: Post-merge howto and FAQ In-Reply-To: References: <1178593238.25550.10.camel@vader.jdub.homelinux.org> <20070509201121.GA5621@nostromo.devel.redhat.com> Message-ID: <200705101258.56747.jamatos@fc.up.pt> On Thursday 10 May 2007 12:25:32 Alex Lancaster wrote: > > etc? It seems a little odd to be carrying forward the "fc" when > Fedora Core will cease to exist as of F7. The common agreement was that fc now stands for Fedora Collection, Fedora is the project and the packages belong to the Fedora Collection. I know that this explanation is not rocket science but it allow us to keep the same prefix followed by the distribution number. :-) > Alex -- Jos? Ab?lio From tcallawa at redhat.com Thu May 10 14:07:59 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 10 May 2007 09:07:59 -0500 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <20070510105147.47f4af4b@ludwig-alpha.unil.ch> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> Message-ID: <1178806079.3570.35.camel@localhost.localdomain> On Thu, 2007-05-10 at 10:51 +0200, Christian Iseli wrote: > Dear all, > > On Wed, 09 May 2007 17:05:05 -0400, Brian Pepple wrote: > > Anyway, please find below the list of > > topics that are likely to come up in the next FESCo meeting that is > > scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on > > irc.freenode.org: > > I won't be able to attend: I have voluntary firefighter training that I > need to attend... > > In case the zope thing comes up again, here is my current view: > - I'm not in favor of a compat-python2.4 package: > o python maintainer doesn't want it > o not in line with a bleeding edge distro > o does not encourage other packages to update to newer version > - I could agree to a runzope package, or maybe even better a > zope-runtime sub-package Since I probably won't be there, due to the RH Summit, my thoughts (and votes if it comes to it): - No compat-python2.4 package Zope has had a LONG time to fix their stuff. Their mailing lists are littered with threads where they admit as much. ~spot From cbalint at redhat.com Thu May 10 15:18:17 2007 From: cbalint at redhat.com (Balint Cristian) Date: Thu, 10 May 2007 17:18:17 +0200 Subject: Package EVR problems in FC+FE 2007-05-02 In-Reply-To: <20070502182250.3ABB9152131@buildsys.fedoraproject.org> References: <20070502182250.3ABB9152131@buildsys.fedoraproject.org> Message-ID: <200705101718.17611.cbalint@redhat.com> Someone asked for this: > iverilog: cbalint AT redhat.com > FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) > FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) Solved today by rebuild on fc7 target in koji. /cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Thu May 10 15:28:00 2007 From: opensource at till.name (Till Maas) Date: Thu, 10 May 2007 17:28:00 +0200 Subject: Package EVR problems in FC+FE 2007-05-02 In-Reply-To: <200705101718.17611.cbalint@redhat.com> References: <20070502182250.3ABB9152131@buildsys.fedoraproject.org> <200705101718.17611.cbalint@redhat.com> Message-ID: <200705101728.01993.opensource@till.name> On Do Mai 10 2007, Balint Cristian wrote: > Someone asked for this: > > iverilog: cbalint AT redhat.com > > FE5 > FE7 (0:0.9.20070421-1.fc5 > 0:0.9.20070227-1.fc7) > > FE6 > FE7 (0:0.9.20070421-1.fc6 > 0:0.9.20070227-1.fc7) > > Solved today by rebuild on fc7 target in koji. As far as I understand the current situation, you need to request the f7-final for your package. The procedure (sending an e-mail) is described, here: http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy Regards, Till From jwboyer at jdub.homelinux.org Thu May 10 15:41:16 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 10 May 2007 10:41:16 -0500 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <1178806079.3570.35.camel@localhost.localdomain> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> Message-ID: <1178811676.22802.42.camel@zod.rchland.ibm.com> On Thu, 2007-05-10 at 09:07 -0500, Tom "spot" Callaway wrote: > On Thu, 2007-05-10 at 10:51 +0200, Christian Iseli wrote: > > Dear all, > > > > On Wed, 09 May 2007 17:05:05 -0400, Brian Pepple wrote: > > > Anyway, please find below the list of > > > topics that are likely to come up in the next FESCo meeting that is > > > scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on > > > irc.freenode.org: > > > > I won't be able to attend: I have voluntary firefighter training that I > > need to attend... > > > > In case the zope thing comes up again, here is my current view: > > - I'm not in favor of a compat-python2.4 package: > > o python maintainer doesn't want it > > o not in line with a bleeding edge distro > > o does not encourage other packages to update to newer version > > - I could agree to a runzope package, or maybe even better a > > zope-runtime sub-package > > Since I probably won't be there, due to the RH Summit, my thoughts (and > votes if it comes to it): > > - No compat-python2.4 package Spot, could you clarify this a bit? Christian stated his opinion on both compat-python2.4 (a generic compat package for the distro) and "runzope" (python 2.4 packaged inside of the zope package). josh From fedora at leemhuis.info Thu May 10 16:00:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 May 2007 18:00:56 +0200 Subject: EPEL status Re: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <1178744705.5807.6.camel@lincoln> References: <1178744705.5807.6.camel@lincoln> Message-ID: <464341B8.6030506@leemhuis.info> Brian Pepple schrieb: > /topic FESCO-Meeting -- MISC -- EPEL Reporting - > https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00713.html My suggestion for this topic can be found at https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00067.html > /topic FESCO-Meeting -- EPEL? Summary from last weeks meeting: https://www.redhat.com/archives/epel-devel-list/2007-May/msg00010.html Happenings during the past week: * Axel steps down from epel; see https://www.redhat.com/archives/epel-devel-list/2007-May/msg00019.html The Steering Committee will look for a successor. * Rebuild for RHEL5 finished; I'll send a "Fedora contributors, if you want to build for EPEL start now mail" with a FAQ over the next few days to this list, as some contributors are waiting for such a mail. But the repo is open for building already, so if Fedora Contributors want to start they are free to do so. But I'll put some more infos into my mail to * I still would like to have some feedback (not more for now) from FESCo members regarding the repotag issue (see https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01232.html ); we discussed it yesterday again in the EPEL Steering Committee meeting, but are still evaluating what to do; looks like some people consider to continue as planed -- e.g. go without them. What do FESCo members think about this topic? FESCo itself voted months ago to go without repotags. CU thl From tcallawa at redhat.com Thu May 10 16:10:54 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 10 May 2007 11:10:54 -0500 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <1178811676.22802.42.camel@zod.rchland.ibm.com> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> Message-ID: <1178813454.3570.39.camel@localhost.localdomain> On Thu, 2007-05-10 at 10:41 -0500, Josh Boyer wrote: > On Thu, 2007-05-10 at 09:07 -0500, Tom "spot" Callaway wrote: > > On Thu, 2007-05-10 at 10:51 +0200, Christian Iseli wrote: > > > Dear all, > > > > > > On Wed, 09 May 2007 17:05:05 -0400, Brian Pepple wrote: > > > > Anyway, please find below the list of > > > > topics that are likely to come up in the next FESCo meeting that is > > > > scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on > > > > irc.freenode.org: > > > > > > I won't be able to attend: I have voluntary firefighter training that I > > > need to attend... > > > > > > In case the zope thing comes up again, here is my current view: > > > - I'm not in favor of a compat-python2.4 package: > > > o python maintainer doesn't want it > > > o not in line with a bleeding edge distro > > > o does not encourage other packages to update to newer version > > > - I could agree to a runzope package, or maybe even better a > > > zope-runtime sub-package > > > > Since I probably won't be there, due to the RH Summit, my thoughts (and > > votes if it comes to it): > > > > - No compat-python2.4 package > > Spot, could you clarify this a bit? Christian stated his opinion on > both compat-python2.4 (a generic compat package for the distro) and > "runzope" (python 2.4 packaged inside of the zope package). I'm not against runzope, per-se, but I'd much much rather see an effort to bring zope to current python. My biggest concern with runzope packaging ideaology is that we'll leave it at that, and not fix the real problem. ~spot From fedora at leemhuis.info Thu May 10 16:32:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 May 2007 18:32:05 +0200 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <1178813454.3570.39.camel@localhost.localdomain> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> <1178813454.3570.39.camel@localhost.localdomain> Message-ID: <46434905.8020407@leemhuis.info> Tom "spot" Callaway schrieb: > On Thu, 2007-05-10 at 10:41 -0500, Josh Boyer wrote: >> On Thu, 2007-05-10 at 09:07 -0500, Tom "spot" Callaway wrote: >>> On Thu, 2007-05-10 at 10:51 +0200, Christian Iseli wrote: >>>> Dear all, >>>> >>>> On Wed, 09 May 2007 17:05:05 -0400, Brian Pepple wrote: >>>>> Anyway, please find below the list of >>>>> topics that are likely to come up in the next FESCo meeting that is >>>>> scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on >>>>> irc.freenode.org: >>>> I won't be able to attend: I have voluntary firefighter training that I >>>> need to attend... >>>> >>>> In case the zope thing comes up again, here is my current view: >>>> - I'm not in favor of a compat-python2.4 package: >>>> o python maintainer doesn't want it >>>> o not in line with a bleeding edge distro >>>> o does not encourage other packages to update to newer version >>>> - I could agree to a runzope package, or maybe even better a >>>> zope-runtime sub-package >>> Since I probably won't be there, due to the RH Summit, my thoughts (and >>> votes if it comes to it): >>> - No compat-python2.4 package >> Spot, could you clarify this a bit? Christian stated his opinion on >> both compat-python2.4 (a generic compat package for the distro) and >> "runzope" (python 2.4 packaged inside of the zope package). > I'm not against runzope, per-se, but I'd much much rather see an effort > to bring zope to current python. > > My biggest concern with runzope packaging ideaology is that we'll leave > it at that, and not fix the real problem. Well, what does that mean for compat-packages in general? Should each of those have a limited life time as well? Or do we need other rules like "packages from the repo are not allowed to use or link against compat packages in the devel tree at release time of a Fedora release"? I just want consistency. We ship about 40 pacakges afaics and we should apply the same rules to all out packages. I fail to understand why python is so special. It's IMHO not just about "python for zope": people might have apps from other sources compiled against python-2.4 installed on their system -- shipping a compat-python24 for one release gives them time to get those apps running after a update to F7 so they can migrate their software to python 2.5 over the next half year until we ship F8. CU thl From tcallawa at redhat.com Thu May 10 16:34:45 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 10 May 2007 11:34:45 -0500 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <46434905.8020407@leemhuis.info> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> <1178813454.3570.39.camel@localhost.localdomain> <46434905.8020407@leemhuis.info> Message-ID: <1178814885.3570.43.camel@localhost.localdomain> On Thu, 2007-05-10 at 18:32 +0200, Thorsten Leemhuis wrote: > Well, what does that mean for compat-packages in general? Should each of > those have a limited life time as well? Or do we need other rules like > "packages from the repo are not allowed to use or link against compat > packages in the devel tree at release time of a Fedora release"? Probably. Jeremy Katz was working on a draft that says as much, although, I haven't seen it yet. ~spot From ville.skytta at iki.fi Thu May 10 20:40:16 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 10 May 2007 23:40:16 +0300 Subject: Summary of the 2007-05-08 Packaging Committee meeting In-Reply-To: References: <464216A7.3020401@hhs.nl> Message-ID: <200705102340.16900.ville.skytta@iki.fi> On Wednesday 09 May 2007, Jason L Tibbitts III wrote: > >>>>> "HdG" == Hans de Goede writes: > > HdG> Long story short, could one or two lines about only adding a > HdG> group and not a user be added? > > I've tacked your request onto the draft so that Ville don't miss it. Thanks, done. More info about the draft in my today's post on -packaging: http://www.redhat.com/archives/fedora-packaging/2007-May/msg00050.html From denis at poolshark.org Fri May 11 11:20:41 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 11 May 2007 13:20:41 +0200 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <46434905.8020407@leemhuis.info> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> <1178813454.3570.39.camel@localhost.localdomain> <46434905.8020407@leemhuis.info> Message-ID: <46445189.10007@poolshark.org> Thorsten Leemhuis wrote: > I just want consistency. We ship about 40 pacakges afaics and we should > apply the same rules to all out packages. I fail to understand why > python is so special. It's IMHO not just about "python for zope": people > might have apps from other sources compiled against python-2.4 installed > on their system -- shipping a compat-python24 for one release gives them > time to get those apps running after a update to F7 so they can migrate > their software to python 2.5 over the next half year until we ship F8. My thoughts exactly. I don't understand why python is so special. If there's community interest in a compat package of an old version of anything (gcc 3.2 for example. it mysteriously disappeared in FC-6 even though the SRPM is in the repo), just let people work on the compat packages. There's too much emphasis on "teaching upstream a lesson", and literally NO emphasis on the interest to end-users. It sounds like some of you are afraid that the word will spread about fedora shipping the old python 2.4 and zope upstream maintainers will suddenly stop all porting efforts. That's absurd. From alexl at users.sourceforge.net Fri May 11 11:37:37 2007 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 11 May 2007 04:37:37 -0700 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <46445189.10007@poolshark.org> (Denis Leroy's message of "Fri\, 11 May 2007 13\:20\:41 +0200") References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> <1178813454.3570.39.camel@localhost.localdomain> <46434905.8020407@leemhuis.info> <46445189.10007@poolshark.org> Message-ID: <8nbqgrwpz2.fsf@delpy.biol.berkeley.edu> >>>>> "DL" == Denis Leroy writes: [...] DL> My thoughts exactly. I don't understand why python is so DL> special. If there's community interest in a compat package of an DL> old version of anything (gcc 3.2 for example. it mysteriously DL> disappeared in FC-6 even though the SRPM is in the repo), just let DL> people work on the compat packages. There's too much emphasis on DL> "teaching upstream a lesson", and literally NO emphasis on the DL> interest to end-users. It sounds like some of you are afraid that DL> the word will spread about fedora shipping the old python 2.4 and DL> zope upstream maintainers will suddenly stop all porting DL> efforts. That's absurd. +1 There needs to a balance between lags in upstream and the interests of users. Bleeding edge shouldn't mean obsoleting things just because they don't always work with the absolutely latest release of everything. Alex From ivazqueznet at gmail.com Fri May 11 12:14:03 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 11 May 2007 08:14:03 -0400 Subject: Reclaiming leafpad Message-ID: <1178885643.6191.11.camel@ignacio.lan> I'd like to take over leafpad which is currently orphaned. I'll post the proper BZ report to have my name put in owners.list. -- Ignacio Vazquez-Abrams -------------- 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 pertusus at free.fr Fri May 11 13:20:23 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 11 May 2007 15:20:23 +0200 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <1178814885.3570.43.camel@localhost.localdomain> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> <1178813454.3570.39.camel@localhost.localdomain> <46434905.8020407@leemhuis.info> <1178814885.3570.43.camel@localhost.localdomain> Message-ID: <20070511132023.GB4791@free.fr> On Thu, May 10, 2007 at 11:34:45AM -0500, Tom spot Callaway wrote: > On Thu, 2007-05-10 at 18:32 +0200, Thorsten Leemhuis wrote: > > > Well, what does that mean for compat-packages in general? Should each of > > those have a limited life time as well? Or do we need other rules like > > "packages from the repo are not allowed to use or link against compat > > packages in the devel tree at release time of a Fedora release"? > > Probably. Jeremy Katz was working on a draft that says as much, > although, I haven't seen it yet. I hope it will only be a best effort and not a requirement... I have used g77 (which is in a compat package) for quite a long time, and I maintain a libnet10 compat package for those who want to use the old api and I hope that it won't be forbidden. Of course we should push upstream to use recent libraries, but we are not in control. -- Pat From gemi at bluewin.ch Fri May 11 18:38:20 2007 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 11 May 2007 20:38:20 +0200 Subject: upgrade to scons 0.96.96 Message-ID: <1178908700.24228.2.camel@localhost.localdomain> It appears that some packages in review need a newer scons version than the stable 0.96.1. See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236517 Is it ok to upgrade, or would some packages currently in the repository break? -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From notting at redhat.com Fri May 11 19:28:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 May 2007 15:28:33 -0400 Subject: koji buildsystem down Message-ID: <20070511192833.GB5522@nostromo.devel.redhat.com> We apologize for the inconvenience, and are working on it. Bill From notting at redhat.com Fri May 11 19:41:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 May 2007 15:41:20 -0400 Subject: koji buildsystem down In-Reply-To: <20070511192833.GB5522@nostromo.devel.redhat.com> References: <20070511192833.GB5522@nostromo.devel.redhat.com> Message-ID: <20070511194120.GA5860@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > We apologize for the inconvenience, and are working on it. Should be better now. Bill From ville.skytta at iki.fi Sat May 12 09:30:39 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 12 May 2007 12:30:39 +0300 Subject: Ex-Core package Makefile.common problem in CVS Message-ID: <200705121230.40181.ville.skytta@iki.fi> Hi, After checking out "rpms" from cvs.fedora.redhat.com:/cvs/pkgs, ex-Core package branch Makefiles have issues finding Makefile.common. Ex-Extras packages don't have that problem - looks like "find-makefile-common" stuff or something similar should be applied to ex-Core branch Makefiles too. For example: $ cd shadow-utils/devel $ make prep Makefile:6: ../common/Makefile.common: No such file or directory make: *** No rule to make target `../common/Makefile.common'. Stop. From fedora at leemhuis.info Sat May 12 11:22:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 May 2007 13:22:30 +0200 Subject: EPEL report 2007, week 19 Message-ID: <4645A376.5010102@leemhuis.info> Hi all! FESCo this week finally decided the details how sub-groups like EPEL should report their doings. In short: there should be weekly reports that must be send to fedora-maintainers for public discussion. The reports also get send to the (private) FESCo-list, to make sure FESCo members don't miss the reports in the noise. This EPEL report is the first one that follows this new scheme -- note that I'll send it to epel-devel-list as well (thus three lists in total!), to make sure non-fedora-contributors that might be interested in EPEL are also aware of what happened and are able join the discussions (they can't on fedora-maintainers, as that's a private list open only for contributors). My preferred discussion ground for replies to this reports would be epel-devel-list, as that's open to everyone -- but I assume some discussions in reply to this reports will happen either on both lists, or just on one. You have been warned. (Side note: I hope we find a better solution after the mailing list reorganisation, which got discussed months ago, but was put on hold until we have new hardware in place and F7 out the door). And another note: In the past EPEL had reports that were meeting-centric -- e.g. mainly the summary of the meetings that happen on Wednesday at 17:00 UTC in #fedora-meeting on freenode. The reports in the future will likely be meeting focused with a summary of the meeting as well, but I'll try to integrate some general notes about what happened in EPEL-land over the last week added as well, so non-EPEL contributors can easily follow all the important happenings. Find the report below! CU knurd ---- = Weekly EPEL Summary = Week 19/2007 == Most important happenings == * Axel Thimm left the EPEL SIG and the EPEL Steering Committee; see https://www.redhat.com/archives/epel-devel-list/2007-May/msg00019.html for details. The Steering Committee is looking for a replacement. * the Steering Committee elected knurd as its chairmen; stahnma will act as backup * now that the RHEL5 rebuild is finished knurd will send a "if you waited for a start signal to build your packages for EPEL this is it" mail over the next few days to fedora-maintainers * repotags -- some discussion in the meeting again. It looks like it will we'll continue without repotags (final decision probably in next weeks meeting, after this summary has been posted and discussed). If you want repotags please *speak up now* and *help* to find a technical solution that is not only fine for the EPEL Steering Committee, but also acceptable for the Fedora Packaging Committee and FESCo -- from discussions on list and on IRC it looks like that some members of those groups tend to be against using repotags (see this weeks FESCo meeting for example) or want to see something cooperation statements signed by EPEL and 3rd party repos before they are willing to accept repotags. In other words: it looks like it will be a whole lot of work to go for repotags in EPEL -- some people might be willing to accept repotags if someone does the wor out the details how to realize them in a way that is acceptable for the different Committees. But it seems nobody is in sight to do it. So if you want repotags and are willing to do that work speak up now -- then there is a chance EPEL might get repotags in the near future. == EPEL SIG Meeting == === Attending === >From the Steering Committee: dgilmore (partially), knurd, mmcgrath (partially), nirik, stahnma Other contributors that joined the meeting: rdieter, smooge === Summary === * knurd was elected as chair by the steering committee in a wiki voting over the past week; stahnma will act as a backup / kind of "vice-president". See http://fedoraproject.org/wiki/EPEL/SteeringCommittee/Voting for details * thimm leaving / vacant seat in the Steering Committee : knurd will mail those people that thimm suggested and ask them if they are willig to become meber of the steering committee. Then we'll decide how to move on. * mass rebuild for RHEL5 -- knurd did rebuild the remaining arch packages over the weekend; issue solved. knurd will send a "if you waited for a start signal to build you packages for epel then this is it" mail to fedora-maintainers over the next few days . knurd and dgilmore will work something out to make branching lots of packages easier. * repotags/interaction with 3rd party repos -- nirik> "we can't keep discussing it forever. " Some discussions to "put our feed down" and go as planed without repotags. See "Most important happenings" for more details * 00:30 and later; some discussions around commitment to EPEL4 stahnma> | is anyone concerned about the lack of package for RHEL 4? It's seems like RHEL 5 has many a but clean up here and there and RHEL 4 has few knurd> | stahnma, well, we have to see how it evolves ; seems some contributors only want to do RHEL5 and later nirik> | there are probibly some things that won't work on rhel4, since versions are old, etc. See full log for all the details * knurd did a some cleanup and additions to the EPEL docs in the wiki and asks people to look over the changes * QA process/testing repo/upload -- we need someone to look into that (bodhi, push scrips) closer. Any volunteers? === Full meeting log === https://www.redhat.com/archives/epel-devel-list/2007-May/msg00031.html == Stats == === EPEL 5 === Number of source packages: 225 Number of binary packages: 373 Packages added over the past week: * boolstuff | Disjunctive Normal Form boolean expression library * php-pear-Structures-DataGrid-DataSource-MDB2 | DataSource driver using PEAR::MDB2 and an SQL query * php-pear-Structures-DataGrid-DataSource-RSS | DataSource driver using RSS files * php-pear-Structures-DataGrid-Renderer-Pager | Renderer driver using PEAR::Pager * pmount | Enable normal user mount * python-Coherence | Python framework to participate in digital living networks * python-decoratortools | Use class and function decorators -- even in Python 2.3 === EPEL 4 === Number of source packages: 158 Number of binary packages: 312 Packages added over the past week: * boolstuff | Disjunctive Normal Form boolean expression library * python-Coherence | Python framework to participate in digital living networks From jwboyer at jdub.homelinux.org Sat May 12 12:45:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 12 May 2007 07:45:58 -0500 Subject: EPEL report 2007, week 19 In-Reply-To: <4645A376.5010102@leemhuis.info> References: <4645A376.5010102@leemhuis.info> Message-ID: <1178973958.17555.7.camel@vader.jdub.homelinux.org> On Sat, 2007-05-12 at 13:22 +0200, Thorsten Leemhuis wrote: > > Find the report below! Overall, looks great. A few comments below. > = Weekly EPEL Summary = > > Week 19/2007 > > == Most important happenings == > > * Axel Thimm left the EPEL SIG and the EPEL Steering Committee; see > https://www.redhat.com/archives/epel-devel-list/2007-May/msg00019.html > for details. The Steering Committee is looking for a replacement. Unfortunate. We wish Axel the best. > * the Steering Committee elected knurd as its chairmen; stahnma will > act as backup Could we use Real Names instead of IRC nicks? I know who knurd is but I don't know who stahnma is. > * now that the RHEL5 rebuild is finished knurd will send a "if you > waited for a start signal to build your packages for EPEL this is it" > mail over the next few days to fedora-maintainers > > * repotags -- some discussion in the meeting again. It looks like it > will we'll continue without repotags (final decision probably in next > weeks meeting, after this summary has been posted and discussed). If you > want repotags please *speak up now* and *help* to find a technical > solution that is not only fine for the EPEL Steering Committee, but also > acceptable for the Fedora Packaging Committee and FESCo -- from > discussions on list and on IRC it looks like that some members of those > groups tend to be against using repotags (see this weeks FESCo meeting > for example) or want to see something cooperation statements signed by > EPEL and 3rd party repos before they are willing to accept repotags. Just some clarification. Yes, FESCo overall didn't see a good reason to use repotags. If EPEL chooses to do so, FESCo won't stand in the way. It would be unfortunate, however, if EPEL and FESCo packaging guidelines diverged. josh From fedora at leemhuis.info Sat May 12 13:10:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 12 May 2007 15:10:54 +0200 Subject: EPEL report 2007, week 19 In-Reply-To: <1178973958.17555.7.camel@vader.jdub.homelinux.org> References: <4645A376.5010102@leemhuis.info> <1178973958.17555.7.camel@vader.jdub.homelinux.org> Message-ID: <4645BCDE.2070203@leemhuis.info> Josh Boyer schrieb: > On Sat, 2007-05-12 at 13:22 +0200, Thorsten Leemhuis wrote: >> Find the report below! > Overall, looks great. A few comments below. thx BTW, I put it into the wiki now, too. http://fedoraproject.org/wiki/EPEL/Reports >> * the Steering Committee elected knurd as its chairmen; stahnma will >> act as backup > Could we use Real Names instead of IRC nicks? I know who knurd is but I > don't know who stahnma is. I tried that in the past and it makes stuff harder and time consuming to write in my experience (I have the nicks from the meeting log already and don't have to type them again or look out how peoples names are spelled correctly). So I prefer to use nicks as writing summaries and reports is boring enough already. >> * repotags -- some discussion in the meeting again. It looks like it >> will we'll continue without repotags (final decision probably in next >> weeks meeting, after this summary has been posted and discussed). If you >> want repotags please *speak up now* and *help* to find a technical >> solution that is not only fine for the EPEL Steering Committee, but also >> acceptable for the Fedora Packaging Committee and FESCo -- from >> discussions on list and on IRC it looks like that some members of those >> groups tend to be against using repotags (see this weeks FESCo meeting >> for example) or want to see something cooperation statements signed by >> EPEL and 3rd party repos before they are willing to accept repotags. > Just some clarification. Yes, FESCo overall didn't see a good reason to > use repotags. If EPEL chooses to do so, FESCo won't stand in the way. FYI: I was a bit against repotags in the past, but my position these days after all this discussions is similar. Or, to be more verbose: If someone works out the details on how to realize repotags in Fedora then (depending on how the proposal looks like) I'll likely abstain from a vote or might even support to use repotags, as long as a simple "cp FC-6/foo.spec EL-5/" remains possible. But I don't have the energy to work out the details. Anyone willing to work them out? > It would be unfortunate, however, if EPEL and FESCo packaging guidelines > diverged. That what I want to prevent, too. CU thl From ivazqueznet at gmail.com Sat May 12 13:28:12 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 12 May 2007 09:28:12 -0400 Subject: Ex-Core package Makefile.common problem in CVS In-Reply-To: <200705121230.40181.ville.skytta@iki.fi> References: <200705121230.40181.ville.skytta@iki.fi> Message-ID: <1178976492.9338.2.camel@ignacio.lan> On Sat, 2007-05-12 at 12:30 +0300, Ville Skytt? wrote: > After checking out "rpms" from cvs.fedora.redhat.com:/cvs/pkgs, ex-Core > package branch Makefiles have issues finding Makefile.common. Ex-Extras > packages don't have that problem - looks like "find-makefile-common" stuff or > something similar should be applied to ex-Core branch Makefiles too. > > For example: > $ cd shadow-utils/devel > $ make prep > Makefile:6: ../common/Makefile.common: No such file or directory > make: *** No rule to make target `../common/Makefile.common'. Stop. Confirmed. And changing the line in Makefile to ../../../common/Makefile.common doesn't work since it gives all sorts of other problems. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Sat May 12 14:38:07 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 12 May 2007 17:38:07 +0300 Subject: Merge/F7 questions In-Reply-To: <200705060000.04269.ville.skytta@iki.fi> References: <200705060000.04269.ville.skytta@iki.fi> Message-ID: <200705121738.07801.ville.skytta@iki.fi> On Sunday 06 May 2007, Ville Skytt? wrote: > Hi, some questions about the merge and F7: Ping, anyone? > 1) When will the EVR of the kernel to be included in the F7 final release > be known, and will there be time to build module packages for it and get > them through rel-eng? > > 2) How can I get the modules built for the f7-final kernel? I just tried > it with em8300-kmod; "koji latest-pkg f7-final kernel" says > kernel-2.6.21-1.3116.fc7 at the moment, but I can no longer build modules > for it as those 1.3116.fc7 kernel(-devel) packages don't seem to be > available for the builders: > https://koji.fedoraproject.org/koji/taskinfo?taskID=3364 > > 3) The new mirror layout at > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge does not show > an "updates" directory for F7, nor mentions what replaces it. Was its > omission from the new layout intentional? If yes, where do package updates > go from F7 on? From dennis at ausil.us Sat May 12 18:36:33 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 12 May 2007 13:36:33 -0500 Subject: Merge/F7 questions In-Reply-To: <200705121738.07801.ville.skytta@iki.fi> References: <200705060000.04269.ville.skytta@iki.fi> <200705121738.07801.ville.skytta@iki.fi> Message-ID: <200705121336.33985.dennis@ausil.us> Once upon a time Saturday 12 May 2007, Ville Skytt? wrote: > On Sunday 06 May 2007, Ville Skytt? wrote: > > Hi, some questions about the merge and F7: > > Ping, anyone? > > > 1) When will the EVR of the kernel to be included in the F7 final release > > be known, and will there be time to build module packages for it and get > > them through rel-eng? > > > > 2) How can I get the modules built for the f7-final kernel? I just tried > > it with em8300-kmod; "koji latest-pkg f7-final kernel" says > > kernel-2.6.21-1.3116.fc7 at the moment, but I can no longer build modules > > for it as those 1.3116.fc7 kernel(-devel) packages don't seem to be > > available for the builders: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=3364 > > > > 3) The new mirror layout at > > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge does not > > show an "updates" directory for F7, nor mentions what replaces it. Was > > its omission from the new layout intentional? If yes, where do package > > updates go from F7 on? I don't know the answers to 1 and 2 but 3 is covered in the page you reference. Dennis From ville.skytta at iki.fi Sat May 12 18:54:58 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 12 May 2007 21:54:58 +0300 Subject: Merge/F7 questions In-Reply-To: <200705121336.33985.dennis@ausil.us> References: <200705060000.04269.ville.skytta@iki.fi> <200705121738.07801.ville.skytta@iki.fi> <200705121336.33985.dennis@ausil.us> Message-ID: <200705122154.58337.ville.skytta@iki.fi> On Saturday 12 May 2007, Dennis Gilmore wrote: > Once upon a time Saturday 12 May 2007, Ville Skytt? wrote: > > > > > > 3) The new mirror layout at > > > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge does not > > > show an "updates" directory for F7, nor mentions what replaces it. Was > > > its omission from the new layout intentional? If yes, where do package > > > updates go from F7 on? > > I don't know the answers to 1 and 2 but 3 is covered in the page you > reference. Where does it mention the updates dir for F7 or the lack of it? From dennis at ausil.us Sat May 12 19:03:32 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 12 May 2007 14:03:32 -0500 Subject: Merge/F7 questions In-Reply-To: <200705122154.58337.ville.skytta@iki.fi> References: <200705060000.04269.ville.skytta@iki.fi> <200705121336.33985.dennis@ausil.us> <200705122154.58337.ville.skytta@iki.fi> Message-ID: <200705121403.32521.dennis@ausil.us> Once upon a time Saturday 12 May 2007, Ville Skytt? wrote: > On Saturday 12 May 2007, Dennis Gilmore wrote: > > Once upon a time Saturday 12 May 2007, Ville Skytt? wrote: > > > > 3) The new mirror layout at > > > > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge does not > > > > show an "updates" directory for F7, nor mentions what replaces it. > > > > Was its omission from the new layout intentional? If yes, where do > > > > package updates go from F7 on? > > > > I don't know the answers to 1 and 2 but 3 is covered in the page you > > reference. > > Where does it mention the updates dir for F7 or the lack of it? With the merger of core and extras, things will change a bit. I'm proposing a new layout: pub/ `-- fedora `-- linux |-- development |-- releases | |-- 6 | |-- 7 | `-- test | |-- 6.90 | |-- 6.91 | `-- 6.92 `-- updates |-- 5 |-- 6 `-- testing |-- 5 `-- 6 so 7 was left off its safe to assume we will have updates for 7 in the same space. From ville.skytta at iki.fi Sat May 12 20:45:51 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 12 May 2007 23:45:51 +0300 Subject: Merge/F7 questions In-Reply-To: <200705121403.32521.dennis@ausil.us> References: <200705060000.04269.ville.skytta@iki.fi> <200705122154.58337.ville.skytta@iki.fi> <200705121403.32521.dennis@ausil.us> Message-ID: <200705122345.52351.ville.skytta@iki.fi> On Saturday 12 May 2007, Dennis Gilmore wrote: > Once upon a time Saturday 12 May 2007, Ville Skytt? wrote: > > > > Where does it mention the updates dir for F7 or the lack of it? > > With the merger of core and extras, things will change a bit. I'm proposing > a new layout: > pub/ > `-- fedora > `-- linux > |-- development > |-- releases > | |-- 6 > | |-- 7 > | `-- test > | |-- 6.90 > | |-- 6.91 > | > | `-- 6.92 > `-- updates > |-- 5 > |-- 6 > `-- testing > |-- 5 > `-- 6 > > so 7 was left off its safe to assume we will have updates for 7 in the same > space. By "in the same space" you mean fedora/linux/releases/7/ ? From jwboyer at jdub.homelinux.org Sat May 12 22:58:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 12 May 2007 17:58:25 -0500 Subject: Merge/F7 questions In-Reply-To: <200705121738.07801.ville.skytta@iki.fi> References: <200705060000.04269.ville.skytta@iki.fi> <200705121738.07801.ville.skytta@iki.fi> Message-ID: <1179010705.17555.19.camel@vader.jdub.homelinux.org> On Sat, 2007-05-12 at 17:38 +0300, Ville Skytt? wrote: > On Sunday 06 May 2007, Ville Skytt? wrote: > > Hi, some questions about the merge and F7: > > Ping, anyone? > > > 1) When will the EVR of the kernel to be included in the F7 final release > > be known, and will there be time to build module packages for it and get > > them through rel-eng? Unknown. DaveJ knows more. > > 2) How can I get the modules built for the f7-final kernel? I just tried > > it with em8300-kmod; "koji latest-pkg f7-final kernel" says > > kernel-2.6.21-1.3116.fc7 at the moment, but I can no longer build modules > > for it as those 1.3116.fc7 kernel(-devel) packages don't seem to be > > available for the builders: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=336 Odd. Have you tried this again with the more recent kernel builds? You could use a scratch build to test it out. josh From dennis at ausil.us Sat May 12 23:51:36 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 12 May 2007 18:51:36 -0500 Subject: Merge/F7 questions In-Reply-To: <200705122345.52351.ville.skytta@iki.fi> References: <200705060000.04269.ville.skytta@iki.fi> <200705121403.32521.dennis@ausil.us> <200705122345.52351.ville.skytta@iki.fi> Message-ID: <200705121851.37475.dennis@ausil.us> Once upon a time Saturday 12 May 2007, Ville Skytt? wrote: > On Saturday 12 May 2007, Dennis Gilmore wrote: > > Once upon a time Saturday 12 May 2007, Ville Skytt? wrote: > > > Where does it mention the updates dir for F7 or the lack of it? > > > > With the merger of core and extras, things will change a bit. I'm > > proposing a new layout: > > pub/ > > `-- fedora > > `-- linux > > > > |-- development > > |-- releases > > | > > | |-- 6 > > | |-- 7 > > | > > | `-- test > > | > > | |-- 6.90 > > | |-- 6.91 > > | > > | `-- 6.92 > > > > `-- updates > > > > |-- 5 > > |-- 6 > > > > `-- testing > > > > |-- 5 > > > > `-- 6 > > > > so 7 was left off its safe to assume we will have updates for 7 in the > > same space. > > By "in the same space" you mean fedora/linux/releases/7/ ? no i mean fedora/linux/updates/7/ fedora/linux/updates/testing/7/ From bugs.michael at gmx.net Sun May 13 12:07:39 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 13 May 2007 14:07:39 +0200 Subject: Announce: No RepoRequests until further notice Message-ID: <20070513140739.4c316b91.bugs.michael@gmx.net> http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests currently won't be processed, since the ongoing merge has made that impossible. Any of the requests on that Wiki page which we've processed in the past involved direct access to the repository. With koji, things have changed. And I'm not in the know and cannot tell whether, when, and how it will be possible again to process such requests. All I can say with my local installation of koji is that removing a package would also need koji admin access to untag builds. For the merged Rawhide that can only be done by the release engineers and not by those who maintained the Extras repositories. Further, for things like copying/hardlinking big noarch builds from devel to FC-6 or vice versa, we need new policies first. Downloading binary builds from koji, signing them manually and inserting them into the Extras repositories would be longwinded and error-prone. From fedora at leemhuis.info Sun May 13 15:30:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 May 2007 17:30:44 +0200 Subject: Start signal: Build your packages for EPEL (if you want to) Message-ID: <46472F24.6070801@leemhuis.info> Hi all! Building you Fedora packages for EPEL (Extra Packages for Enterprise Linux -- http://fedoraproject.org/wiki/EPEL ) is possible for some months now. But it seem lots of Fedora contributors wait for a kind of start signal to begin. *This mail is this start signal*, as we have all the important pieces in place now! So go and build your Fedora packages for EPEL if you want, to have your packages easily available for RHEL and compatible derivates such as CentOS or Scientific Linux in the future as well! Don't know what EPEL is? Want to know what is special or different from contributing to EPEL? Then read on! What is EPEL about? EPEL is a kind of Fedora Extras for Red Hat Enterprise Linux (Versions 4 and 5 only atm) and compatible derivates such as CentOS or Scientific Linux. The repo is available already at http://download.fedora.redhat.com/pub/epel/ -- but please note that the repo it's not yet ready for general public consumption. We'd like to fill the repo a bit more (hence this mail) before we announce EPEL for general use; there are also some small details that need to be sorted out before we can announce EPEL for real. Why is the Fedora project running EPEL? Simple: RHEL is derivated from Fedora, but doesn't ship everything that is part of Fedora Core or Extras -- but some people (both contributors and users) would like to easily use those packages on RHEL-based distributions as well, as they are familiar with them from Fedora already. EPEL wants to fill that gap and provide those Fedora packages that are not part of RHEL and derivates. Doing so should be easy: the Fedora project has all the spec files for those packages missing in RHEL already. And even better: as RHEL and its derivates are quite similar to specific Fedora releases building a package for EPEL is often as simple as rebuilding the Fedora SRPM on RHEL. For example many of the Fedora Core 6 SRPM build fine on RHEL5; many of the Fedora Core 3 SRPMS build fine on RHEL4 (note: this of course only as long as all BuildRequires are are available already). What do I have to to do to request a EPEL branch? You can use the normal bugzilla procedure to request a EPEL-branch (they are named EL-4 and EL-5). We offer a shortcut if you want to get lots of packages branched: * if you want EPEL branches for all your packages simply send a string "foo at bar.baz EL-5" or "foo at bar.baz EL-4" to dennis at ausil.us; Dennis Gilmore then will branch all packages that are owned by foo at bar.baz for the the requested EPEL branches * if you want EPEL branches for lots of packages simply send strings like "foo at bar.baz EL-5 pgk1 pgk2 pgk3" to dennis at ausil.us; Dennis Gilmore then will branch pgk1 pgk2 and pgk3 for EPEL and assign foo at bar.baz as EPEL-owner Please be patient after sending those mails; it might take some days until Dennis gets all the requests fulfillt. I don't have a RHEL subscription -- how can I test my package? Use CentOS for build- and runtime checks. The mock package found in Fedora actually ships proper mock config files for EPEL4 that you can simply use for buildtime testing with a command such as "mock -r fedora-4-i386-epel.cfg foo.src.rpm". The config files for EPEL5 are not yet part of mock; you can find them attached. Is EPEL a rolling release like Fedora Extras was? No, the plan is to have a update strategy similar to the one from RHEL. E.g. ship software once and only update it to later versions if there is a strong need -- so no "hey, there is a new version, it builds, let's ship it" mentality in EPEL please. See http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies for more details. Can packages from EPEL replace packages for RHEL? No, EPEL packages are not allowed to replace or disturb packages from RHEL. Not all the build- and runtime-dependencies I need are available in EPEL. How do I get them? Please read http://fedoraproject.org/wiki/EPEL/ContributorStatus -- and please flip the EPEL bit behind your name so other EPEL contributors know if you are committed to EPEL or not. What does EPEL differentiate from existing repos for RHEL? We respect other repos (and their maintainers) and expect to target a different user base with our quite careful, RHEL-like update strategy. Some more questions and answers can be found on: http://fedoraproject.org/wiki/EPEL/FAQ It's likely that this document and the FAQ won't answer all question, but it should be a start and we'll improve the document as questions arise. Just ask here on the list, on epel-devel-list at redhat.com or in #epel on Freenode. CU knurd -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-i386-epel.cfg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-ppc-epel.cfg URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora-5-x86_64-epel.cfg URL: From fedora at leemhuis.info Sun May 13 15:39:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 May 2007 17:39:25 +0200 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <46472F24.6070801@leemhuis.info> References: <46472F24.6070801@leemhuis.info> Message-ID: <4647312D.1060104@leemhuis.info> Me again! I wanted to send this as a separate shorter mail on purpose, in the hope that more people read a short mail about EPEL, even if they are not interested. Thorsten Leemhuis wrote: > Not all the build- and runtime-dependencies I need are available in > EPEL. How do I get them? Please read > http://fedoraproject.org/wiki/EPEL/ContributorStatus -- and please flip > the EPEL bit behind your name so other EPEL contributors know if you are > committed to EPEL or not. If you are a Fedora contributors please go to http://fedoraproject.org/wiki/EPEL/ContributorStatus , skim over the fist paras quickly, edit the page, look out for your name/email and update the last cell in that row (it's the one "Interested in maintaining packages in EPEL" column) to either "yes", "no", "partly" or "unsure". Even if you are not interested in EPEL updating the page like this is in your own interest to avoid that EPEL contributors bug you with questions if you participate in EPEL. Thanks in advance! Note: the page was generated weeks ago; so recent contributors might be missing (simply add yourself please) and the number of packages is not fully accurate (it's there for other purposes, so this can be ignored). CU thl From belegdol at gmail.com Sun May 13 18:05:53 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Sun, 13 May 2007 19:05:53 +0100 Subject: another goffice package Message-ID: <46475381.4040505@gmail.gom> Hi, according to the discussion in bug #239545, it looks like it won't be possible to update goffice to 0.4.x branch anytime soon, even in f8 rawhide, due to the fact that stable branches of gnumeric and abiword are not yet ready for it. On the other hand, new gnome-chemistry-utils (and especially gchempaint), will be out on 19th and offer some very nice improvements. So, my question is, are there any objections for pushing goffice04 package to f7 and f8 rawhide once the freeze ends, given the fact that both versions can be installed in parallel? It could be obsoleted by goffice later on once gnumeric and abiword are ready. Regards, Julian From j.w.r.degoede at hhs.nl Sun May 13 20:37:52 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 13 May 2007 22:37:52 +0200 Subject: another goffice package In-Reply-To: <46475381.4040505@gmail.gom> References: <46475381.4040505@gmail.gom> Message-ID: <46477720.4040708@hhs.nl> Julian Sikorski wrote: > Hi, > > according to the discussion in bug #239545, it looks like it won't be > possible to update goffice to 0.4.x branch anytime soon, even in f8 > rawhide, due to the fact that stable branches of gnumeric and abiword > are not yet ready for it. On the other hand, new gnome-chemistry-utils > (and especially gchempaint), will be out on 19th and offer some very > nice improvements. So, my question is, are there any objections for > pushing goffice04 package to f7 and f8 rawhide once the freeze ends, > given the fact that both versions can be installed in parallel? It could > be obsoleted by goffice later on once gnumeric and abiword are ready. > No objection from me (I'm the goffice maintainer), if you submit a review for this please put me in the CC. Regards, Hans From j.w.r.degoede at hhs.nl Sun May 13 20:45:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 13 May 2007 22:45:01 +0200 Subject: Announce: No RepoRequests until further notice In-Reply-To: <20070513140739.4c316b91.bugs.michael@gmx.net> References: <20070513140739.4c316b91.bugs.michael@gmx.net> Message-ID: <464778CD.60501@hhs.nl> Michael Schwendt wrote: > http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests > > currently won't be processed, since the ongoing merge has made that > impossible. > > Any of the requests on that Wiki page which we've processed in the past > involved direct access to the repository. With koji, things have > changed. And I'm not in the know and cannot tell whether, when, and how it > will be possible again to process such requests. All I can say with my > local installation of koji is that removing a package would also need koji > admin access to untag builds. For the merged Rawhide that can only be done > by the release engineers and not by those who maintained the Extras > repositories. > > Further, for things like copying/hardlinking big noarch builds from devel > to FC-6 or vice versa, we need new policies first. Downloading binary > builds from koji, signing them manually and inserting them into the > Extras repositories would be longwinded and error-prone. > IOW, For the vegastrike-data package to get into FC-6 (which it needs to be to stop broken deps) I should request an FC-6 branch and build it there, correct? I guess I could still leave it disttagless, so that people upgrading from FC6 -> F7 will not need to download 100 Mb just for the fun of it? Regards, Hans From wtogami at redhat.com Mon May 14 02:55:01 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 13 May 2007 22:55:01 -0400 Subject: Remove /cvs/dist, symlink to /cvs/pkgs? Message-ID: <4647CF85.8020808@redhat.com> Before Merge: /cvs/dist replicated copy of Core from RH's internal CVS /cvs/extras After Merge: /cvs/dist no longer updated) /cvs/pkgs moved from /cvs/extras with /cvs/dist stuff merged into it /cvs/extras symlink pointing at /cvs/pkgs Why not remove /cvs/dist and symlink it to /cvs/pkgs too? OK well, I guess it isn't that simple because FC-5 and FC-6 still needs to be replicated from RH's /cvs/dist. Is it possible to symlink only devel for now? Warren Togami wtogami at redhat.com From tgl at redhat.com Mon May 14 05:42:17 2007 From: tgl at redhat.com (Tom Lane) Date: Mon, 14 May 2007 01:42:17 -0400 Subject: Remove /cvs/dist, symlink to /cvs/pkgs? In-Reply-To: <4647CF85.8020808@redhat.com> References: <4647CF85.8020808@redhat.com> Message-ID: <26128.1179121337@sss.pgh.pa.us> Warren Togami writes: > Why not remove /cvs/dist and symlink it to /cvs/pkgs too? Didn't we remove /cvs/pkgs in favor of /cvs/dist just a couple years ago? Maybe this is just part of a plan to keep developers on their toes. Randomly rename the repository every so often, just to see who is able to keep up with the game... regards, tom lane From luya_tfz at thefinalzone.com Mon May 14 06:33:47 2007 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Sun, 13 May 2007 23:33:47 -0700 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <4647312D.1060104@leemhuis.info> References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> Message-ID: <464802CB.8030309@thefinalzone.com> Thorsten Leemhuis wrote: > Me again! > > I wanted to send this as a separate shorter mail on purpose, in the hope > that more people read a short mail about EPEL, even if they are not > interested. > > Thorsten Leemhuis wrote: > > If you are a Fedora contributors please go to > http://fedoraproject.org/wiki/EPEL/ContributorStatus , skim over the > fist paras quickly, edit the page, look out for your name/email and > update the last cell in that row (it's the one "Interested in > maintaining packages in EPEL" column) to either "yes", "no", "partly" or > "unsure". > > What if some contributors don't have either Centos or RHEL installed? -- Luya Tshimbalanga http://www.fedoraproject.org/wiki/LuyaTshimbalanga Fedora Art Team From frank-buettner at gmx.net Mon May 14 06:38:24 2007 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Mon, 14 May 2007 08:38:24 +0200 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <464802CB.8030309@thefinalzone.com> References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> <464802CB.8030309@thefinalzone.com> Message-ID: <464803E0.50000@gmx.net> Luya Tshimbalanga schrieb: > Thorsten Leemhuis wrote: >> Me again! >> >> I wanted to send this as a separate shorter mail on purpose, in the hope >> that more people read a short mail about EPEL, even if they are not >> interested. >> >> Thorsten Leemhuis wrote: >> >> If you are a Fedora contributors please go to >> http://fedoraproject.org/wiki/EPEL/ContributorStatus , skim over the >> fist paras quickly, edit the page, look out for your name/email and >> update the last cell in that row (it's the one "Interested in >> maintaining packages in EPEL" column) to either "yes", "no", "partly" or >> "unsure". >> >> > What if some contributors don't have either Centos or RHEL installed? > Take vmware or XEN and build one. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From rc040203 at freenet.de Mon May 14 06:54:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 08:54:25 +0200 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <464803E0.50000@gmx.net> References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> <464802CB.8030309@thefinalzone.com> <464803E0.50000@gmx.net> Message-ID: <1179125665.4735.302.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 08:38 +0200, Frank B?ttner wrote: > Luya Tshimbalanga schrieb: > > Thorsten Leemhuis wrote: > >> Me again! > >> > >> I wanted to send this as a separate shorter mail on purpose, in the hope > >> that more people read a short mail about EPEL, even if they are not > >> interested. > >> > >> Thorsten Leemhuis wrote: > >> > >> If you are a Fedora contributors please go to > >> http://fedoraproject.org/wiki/EPEL/ContributorStatus , skim over the > >> fist paras quickly, edit the page, look out for your name/email and > >> update the last cell in that row (it's the one "Interested in > >> maintaining packages in EPEL" column) to either "yes", "no", "partly" or > >> "unsure". > >> > >> > > What if some contributors don't have either Centos or RHEL installed? > > > Take vmware or XEN and build one. Or simply decide not to support it. Ralf From triad at df.lth.se Mon May 14 09:12:47 2007 From: triad at df.lth.se (Linus Walleij) Date: Mon, 14 May 2007 11:12:47 +0200 (CEST) Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <4647312D.1060104@leemhuis.info> References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> Message-ID: There is just one thing I wanted to know, 'cause the FAQ doesn't say, and it really should: * What is the expected length of the support-cycle for an EPEL release? How long should you expect to be security-fixing and handling bugs for the package until the EPEL release is considered obsolete? I expect the answer to be == the support cycle length of RHEL which I don't know either, so please elaborate. Linus From bugs.michael at gmx.net Mon May 14 10:07:08 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 14 May 2007 12:07:08 +0200 Subject: vegastrike-data - Re: Announce: No RepoRequests until further notice In-Reply-To: <464778CD.60501@hhs.nl> References: <20070513140739.4c316b91.bugs.michael@gmx.net> <464778CD.60501@hhs.nl> Message-ID: <20070514120708.91913934.bugs.michael@gmx.net> On Sun, 13 May 2007 22:45:01 +0200, Hans de Goede wrote: > IOW, > > For the vegastrike-data package to get into FC-6 (which it needs to be to stop > broken deps) I should request an FC-6 branch and build it there, correct? > > I guess I could still leave it disttagless, so that people upgrading from FC6 > -> F7 will not need to download 100 Mb just for the fun of it? I'm going to process the vegastrike-data request, but I cannot do anything about new devel requests. Rawhide lives elsewhere, we cannot hardlink signed packages, we cannot save the disk space. And Rawhide repo maintenance is in the hands of other people. Whether you could build for FC-6 from a devel cvs tag, I have forgotten. :) I have tried that long ago to know whether it's possible, and I seem to recall it is not possible. From j.w.r.degoede at hhs.nl Mon May 14 11:24:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 14 May 2007 13:24:23 +0200 Subject: vegastrike-data - Re: Announce: No RepoRequests until further notice In-Reply-To: <20070514120708.91913934.bugs.michael@gmx.net> References: <20070513140739.4c316b91.bugs.michael@gmx.net> <464778CD.60501@hhs.nl> <20070514120708.91913934.bugs.michael@gmx.net> Message-ID: <464846E7.3070808@hhs.nl> Michael Schwendt wrote: > On Sun, 13 May 2007 22:45:01 +0200, Hans de Goede wrote: > >> IOW, >> >> For the vegastrike-data package to get into FC-6 (which it needs to be to stop >> broken deps) I should request an FC-6 branch and build it there, correct? >> >> I guess I could still leave it disttagless, so that people upgrading from FC6 >> -> F7 will not need to download 100 Mb just for the fun of it? > > I'm going to process the vegastrike-data request Thanks! Regards, Hans From jwboyer at jdub.homelinux.org Mon May 14 11:46:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 06:46:06 -0500 Subject: Remove /cvs/dist, symlink to /cvs/pkgs? In-Reply-To: <26128.1179121337@sss.pgh.pa.us> References: <4647CF85.8020808@redhat.com> <26128.1179121337@sss.pgh.pa.us> Message-ID: <1179143166.19267.8.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 01:42 -0400, Tom Lane wrote: > Warren Togami writes: > > Why not remove /cvs/dist and symlink it to /cvs/pkgs too? > > Didn't we remove /cvs/pkgs in favor of /cvs/dist just a couple years > ago? > > Maybe this is just part of a plan to keep developers on their toes. > Randomly rename the repository every so often, just to see who is > able to keep up with the game... Yes, that's our plan. You get 2 gold stars for figuring it out. josh From jwboyer at jdub.homelinux.org Mon May 14 11:47:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 06:47:06 -0500 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> Message-ID: <1179143226.19267.10.camel@vader.jdub.homelinux.org> On Mon, 2007-05-14 at 11:12 +0200, Linus Walleij wrote: > There is just one thing I wanted to know, 'cause the FAQ doesn't say, and > it really should: > > * What is the expected length of the support-cycle for an EPEL release? > How long should you expect to be security-fixing and handling bugs for > the package until the EPEL release is considered obsolete? 7 years. > I expect the answer to be == the support cycle length of RHEL which I > don't know either, so please elaborate. Yes. 7 years. josh From belegdol at gmail.com Mon May 14 12:00:20 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 14 May 2007 13:00:20 +0100 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <1179143226.19267.10.camel@vader.jdub.homelinux.org> References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> <1179143226.19267.10.camel@vader.jdub.homelinux.org> Message-ID: <9b1b20e70705140500r73dd5297yf39e3660c6b0673b@mail.gmail.com> It looks like my account was deleted from wiki... Weird. From SteveD at redhat.com Mon May 14 14:48:57 2007 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 14 May 2007 10:48:57 -0400 Subject: What happen to wireshark? Message-ID: <464876D9.3020402@RedHat.com> I'm doing a dvd install of FC7 (test4) and could not find the option to install wireshark? Has that package been dropped? steved. From katzj at redhat.com Mon May 14 14:48:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 14 May 2007 10:48:18 -0400 Subject: What happen to wireshark? In-Reply-To: <464876D9.3020402@RedHat.com> References: <464876D9.3020402@RedHat.com> Message-ID: <1179154098.12077.29.camel@aglarond.local> On Mon, 2007-05-14 at 10:48 -0400, Steve Dickson wrote: > I'm doing a dvd install of FC7 (test4) and could not find the option > to install wireshark? Has that package been dropped? It looks like it's not in the manifest for the DVD. But note that this is off-topic for this list and is better suited to fedora-devel-list where more people can be involved in the discussion Jeremy From katzj at redhat.com Mon May 14 14:52:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 14 May 2007 10:52:09 -0400 Subject: Merge/F7 questions In-Reply-To: <200705060000.04269.ville.skytta@iki.fi> References: <200705060000.04269.ville.skytta@iki.fi> Message-ID: <1179154329.12077.35.camel@aglarond.local> On Sun, 2007-05-06 at 00:00 +0300, Ville Skytt? wrote: > 1) When will the EVR of the kernel to be included in the F7 final release be > known, and will there be time to build module packages for it and get them > through rel-eng? Unfortunately, the kernel is one of those things that ends up being built until the last minute :/ There should be time to build module packages for it, though as there aren't any module packages on the media making things a smidge easier. Dave is probably in the best position to do a "heads-up; this is hopefully the final kernel" mail when we're there. > 2) How can I get the modules built for the f7-final kernel? I just tried it > with em8300-kmod; "koji latest-pkg f7-final kernel" says > kernel-2.6.21-1.3116.fc7 at the moment, but I can no longer build modules for > it as those 1.3116.fc7 kernel(-devel) packages don't seem to be available for > the builders: https://koji.fedoraproject.org/koji/taskinfo?taskID=3364 This should be a bit better now that davej can tag the kernels himself which should keep things better synced. > 3) The new mirror layout at > http://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge does not show > an "updates" directory for F7, nor mentions what replaces it. Was its > omission from the new layout intentional? If yes, where do package updates > go from F7 on? /pub/fedora/linux/updates/7 (and it looks like the wiki page got updated for this) Jeremy From sundaram at fedoraproject.org Mon May 14 15:30:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 May 2007 21:00:38 +0530 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <9b1b20e70705140500r73dd5297yf39e3660c6b0673b@mail.gmail.com> References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> <1179143226.19267.10.camel@vader.jdub.homelinux.org> <9b1b20e70705140500r73dd5297yf39e3660c6b0673b@mail.gmail.com> Message-ID: <4648809E.20109@fedoraproject.org> Julian Sikorski wrote: > It looks like my account was deleted from wiki... Weird. Were you affected by this? https://www.redhat.com/archives/fedora-announce-list/2007-April/msg00002.html Rahul From belegdol at gmail.com Mon May 14 15:45:37 2007 From: belegdol at gmail.com (Julian Sikorski) Date: Mon, 14 May 2007 16:45:37 +0100 Subject: Please help the EPEL effort a bit even if you don't participate in EPEL In-Reply-To: <4648809E.20109@fedoraproject.org> References: <46472F24.6070801@leemhuis.info> <4647312D.1060104@leemhuis.info> <1179143226.19267.10.camel@vader.jdub.homelinux.org> <9b1b20e70705140500r73dd5297yf39e3660c6b0673b@mail.gmail.com> <4648809E.20109@fedoraproject.org> Message-ID: <9b1b20e70705140845h2011af67je7fcc6a702a57175@mail.gmail.com> 2007/5/14, Rahul Sundaram : > Julian Sikorski wrote: > > It looks like my account was deleted from wiki... Weird. > > > Were you affected by this? > > https://www.redhat.com/archives/fedora-announce-list/2007-April/msg00002.html > > Rahul > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > Probably. Will have to re-register then. From notting at redhat.com Mon May 14 16:56:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 14 May 2007 12:56:40 -0400 Subject: Remove /cvs/dist, symlink to /cvs/pkgs? In-Reply-To: <4647CF85.8020808@redhat.com> References: <4647CF85.8020808@redhat.com> Message-ID: <20070514165640.GB5267@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Before Merge: > /cvs/dist replicated copy of Core from RH's internal CVS > /cvs/extras > > After Merge: > /cvs/dist no longer updated) > /cvs/pkgs moved from /cvs/extras with /cvs/dist stuff merged into it > /cvs/extras symlink pointing at /cvs/pkgs > > Why not remove /cvs/dist and symlink it to /cvs/pkgs too? OK well, I > guess it isn't that simple because FC-5 and FC-6 still needs to be > replicated from RH's /cvs/dist. Is it possible to symlink only devel > for now? Seems more complex to just try and link particular branches. Bill From ivazqueznet at gmail.com Mon May 14 17:58:27 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 14 May 2007 13:58:27 -0400 Subject: branches/dist abstraction patch Message-ID: <1179165507.7498.8.camel@ignacio.lan> The attached patch and file provides separation between the distvar (fedora, rhel, etc.) and the project (core, epel, etc.) in the branches system in CVS. It also adds a bit of documentation to the branches file. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common.patch Type: text/x-patch Size: 1054 bytes Desc: not available URL: -------------- next part -------------- #::::: # branch: CVS branch (RHL-9, FC-3, EL-4, etc.) # distro: Distro and version (rhl8, fc3, el4, etc.) # disttag: Package suffix (.rhl8, .fc3, .el4, etc.) # distvar: Variable to test in the spec file (rhl, fedora, rhel, etc.) # distval: Value to set the above variable to (8, 3, 4, etc.) # project: Project the branch belongs to (legacy, core, epel, etc.) RHL-7:rhl7:.rhl7:rhl:7:legacy RHL-8:rhl8:.rhl8:rhl:8:legacy RHL-9:rhl9:.rhl9:rhl:9:legacy EL-4:el4:.el4:rhel:4:epel EL-5:el5:.el5:rhel:5:epel FC-1:fc1:.fc1:fedora:1:legacy FC-2:fc2:.fc2:fedora:2:legacy FC-3:fc3:.fc3:fedora:3:core FC-4:fc4:.fc4:fedora:4:core FC-5:fc5:.fc5:fedora:5:core FC-6:fc6:.fc6:fedora:6:core devel:dist-fc7:.fc7:fedora:7:core -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Mon May 14 20:42:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 15:42:51 -0500 Subject: Broken upgrade paths in F7 Message-ID: <1179175371.19267.39.camel@vader.jdub.homelinux.org> Hi All, Below you'll find the broken upgrade paths report for the current F7 rawhide repository. Thanks to Kevin Fenzi for running this report. To date, there are only 5 packages out of this entire list that appear to be actually broken. The rest all have builds sitting in the dist-fc7 tag that would fix the upgrade path problem. I will attach that report shortly. josh asymptote: FE5 > F7 (0:1.28-1.fc5 > 0:1.26-1.fc7) FE6 > F7 (0:1.28-1.fc6 > 0:1.26-1.fc7) bitlbee: FE5 > F7 (0:1.0.3-6.fc5 > 0:1.0.3-5.fc7) FE6 > F7 (0:1.0.3-6.fc6 > 0:1.0.3-5.fc7) cacti: FE5 > F7 (0:0.8.6j-1.fc5 > 0:0.8.6i-5.fc7) FE6 > F7 (0:0.8.6j-1.fc6 > 0:0.8.6i-5.fc7) cups-pdf: FE5 > F7 (0:2.4.6-1.fc5 > 0:2.4.5-1.fc7.1) FE6 > F7 (0:2.4.6-1.fc6 > 0:2.4.5-1.fc7.1) cyphesis: FE6 > F7 (0:0.5.12-1.fc6 > 0:0.5.11-2.fc7) dap-server: FE6 > F7 (0:3.7.4-2.fc6 > 0:3.7.1-4.fc7) duplicity: FE5 > F7 (0:0.4.2-7.fc5 > 0:0.4.2-6.fc7) FE6 > F7 (0:0.4.2-7.fc6 > 0:0.4.2-6.fc7) eclipse-cdt: FC6-updates > F7 (1:3.1.2-3.fc6 > 1:3.1.2-2.fc7) eggdrop: FE5 > F7 (0:1.6.18-8.fc5 > 0:1.6.18-7.fc7) FE6 > F7 (0:1.6.18-8.fc6 > 0:1.6.18-7.fc7) em8300: FE6 > F7 (0:0.16.2-1.fc6 > 0:0.16.2-0.1.rc1.fc7) em8300-kmod: FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) fortune-firefly: FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-2.fc6 > 0:2.1.1-2.fc6) funtools: FE5 > FE6 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc6) FE5 > F7 (0:1.3.0-0.5.b33.fc5 > 0:1.3.0-0.4.b29.fc7) fuse: FE5 > F7 (0:2.6.5-1.fc5 > 0:2.6.3-2.fc7) FE6 > F7 (0:2.6.5-1.fc6 > 0:2.6.3-2.fc7) gallery2: FE5 > F7 (0:2.2-0.4.svn20070506.fc5 > 0:2.1-0.24.svn20060817.fc6) FE6 > F7 (0:2.2-0.4.svn20070506.fc6 > 0:2.1-0.24.svn20060817.fc6) gdal: FE6 > F7 (0:1.4.1-1.fc6 > 0:1.4.0-22.fc7) ghc: FE6 > F7 (0:6.6.1-2.fc6 > 0:6.6-2.fc7) gnash: FE5 > F7 (0:0.7.2-2.fc5 > 0:0.7.2-1.fc7) FE6 > F7 (0:0.7.2-2.fc6 > 0:0.7.2-1.fc7) gtk+extra: FE6 > F7 (0:2.1.1-4.fc6 > 0:2.1.1-3.fc6) gtk2hs: FE6 > F7 (0:0.9.11-3.fc6 > 0:0.9.11-2.fc7) hdf: FE6 > F7 (0:4.2r1-13.fc6 > 0:4.2r1-12.fc7) htmldoc: FE5 > F7 (0:1.8.27-2.fc5 > 0:1.8.27-1.fc6.1) FE6 > F7 (0:1.8.27-2.fc6 > 0:1.8.27-1.fc6.1) koji: FE6 > F7 (0:1.1-2.fc6 > 0:1.1-1.fc7) libopm: FE5 > F7 (0:0.1-4.20050731cvs.fc5 > 0:0.1-3.20050731cvs.fc7) FE6 > F7 (0:0.1-4.20050731cvs.fc6 > 0:0.1-3.20050731cvs.fc7) librfid: FE6 > F7 (0:0.1.0-3.1996svn.fc6 > 0:0.1.0-2.fc7) librsync: FE5 > F7 (0:0.9.7-10.fc5 > 0:0.9.7-9.fc7) FE6 > F7 (0:0.9.7-10.fc6 > 0:0.9.7-9.fc7) libxml2: FC6-updates > F7 (0:2.6.28-1.fc6 > 0:2.6.28-1) m4: FC6-updates > F7 (0:1.4.8-2 > 0:1.4.8-1) mbuffer: FE5 > F7 (0:20070502-1.fc5 > 0:20070401-1.fc7) FE6 > F7 (0:20070502-1.fc6 > 0:20070401-1.fc7) mimedefang: FE5 > F7 (0:2.62-2.fc5 > 0:2.62-1.fc7) FE6 > F7 (0:2.62-2.fc6 > 0:2.62-1.fc7) moin: FE5 > F7 (0:1.5.7-2.fc5 > 0:1.5.7-1.fc7) FE6 > F7 (0:1.5.7-2.fc6 > 0:1.5.7-1.fc7) opensc: FE6 > F7 (0:0.11.2-2.fc6 > 0:0.11.2-0.3.rc2.fc7) pan: FE6 > F7 (1:0.129-1.fc6 > 1:0.127-1.fc7) perl-CGI-Ex: FE5 > F7 (0:2.12-1.fc5 > 0:2.10-2.fc7) FE6 > F7 (0:2.12-1.fc6 > 0:2.10-2.fc7) perl-Data-Alias: FE5 > F7 (0:1.04-1.fc5 > 0:1.02-1.fc7) FE6 > F7 (0:1.04-1.fc6 > 0:1.02-1.fc7) perl-File-Copy-Recursive: FE6 > F7 (0:0.33-1.fc6 > 0:0.31-2.fc7) perl-File-Next: FE5 > F7 (0:0.40-1.fc5 > 0:0.38-2.fc7) FE6 > F7 (0:0.40-1.fc6 > 0:0.38-2.fc7) perl-JSON: FE5 > F7 (0:1.14-1.fc5 > 0:1.11-2.fc7) FE6 > F7 (0:1.14-1.fc6 > 0:1.11-2.fc7) perl-Module-Refresh: FE5 > F7 (0:0.13-1.fc5 > 0:0.11-1.fc7) FE6 > F7 (0:0.13-1.fc6 > 0:0.11-1.fc7) perl-Module-ScanDeps: FE5 > F7 (0:0.74-1.fc5 > 0:0.73-1.fc7) FE6 > F7 (0:0.74-1.fc6 > 0:0.73-1.fc7) perl-Moose: FE5 > F7 (0:0.21-1.fc5 > 0:0.20-1.fc7) FE6 > F7 (0:0.21-1.fc6 > 0:0.20-1.fc7) perl-Net-LibIDN: FE5 > F7 (0:0.09-3.fc5 > 0:0.09-2.fc7) FE6 > F7 (0:0.09-3.fc6 > 0:0.09-2.fc7) perl-Pod-Strip: FE5 > F7 (0:1.02-2.fc5 > 0:1.02-1.fc7) FE6 > F7 (0:1.02-2.fc6 > 0:1.02-1.fc7) perl-POE-Component-Client-Keepalive: FE5 > F7 (0:0.1000-1.fc5 > 0:0.0901-1.fc6) FE6 > F7 (0:0.1000-1.fc6 > 0:0.0901-1.fc6) perl-POE-Component-IRC: FE5 > F7 (0:5.29-1.fc5 > 0:5.26-1.fc7) FE6 > F7 (0:5.29-1.fc6 > 0:5.26-1.fc7) perl-POE-Component-SSLify: FE6 > F7 (0:0.07-1.fc6 > 0:0.06-1.fc6) perl-Test-Warn: FE5 > F7 (0:0.10-1.fc5 > 0:0.09-1.fc7) FE6 > F7 (0:0.10-1.fc6 > 0:0.09-1.fc7) perl-Text-Glob: FE5 > F7 (0:0.08-1.fc5 > 0:0.07-2.fc6) FE6 > F7 (0:0.08-1.fc6 > 0:0.07-2.fc6) perl-Want: FE5 > F7 (0:0.14-1.fc5 > 0:0.12-2.fc7) FE6 > F7 (0:0.14-1.fc6 > 0:0.12-2.fc7) php-idn: FE5 > F7 (0:1.2-2.fc5 > 0:1.2-1.fc7) FE6 > F7 (0:1.2-2.fc6 > 0:1.2-1.fc7) php-pear-DB-DataObject-FormBuilder: FE5 > F7 (0:1.0.0-0.5.RC7.fc5 > 0:1.0.0-0.4.RC7.fc7) FE6 > F7 (0:1.0.0-0.5.RC7.fc6 > 0:1.0.0-0.4.RC7.fc7) php-pear-MDB2: FE5 > F7 (0:2.4.1-1.fc5 > 0:2.4.0-1.fc7) FE6 > F7 (0:2.4.1-1.fc6 > 0:2.4.0-1.fc7) php-pear-MDB2-Driver-mysql: FE5 > F7 (0:1.4.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.4.1-1.fc6 > 0:1.4.0-1.fc7) php-pear-Net-Socket: FE5 > F7 (0:1.0.8-1.fc5 > 0:1.0.7-1.fc7) FE6 > F7 (0:1.0.8-1.fc6 > 0:1.0.7-1.fc7) php-pear-Structures-DataGrid-DataSource-DataObject: FE5 > F7 (0:0.1.2-1.fc5 > 0:0.1.1-1.fc7) FE6 > F7 (0:0.1.2-1.fc6 > 0:0.1.1-1.fc7) python-kaa-metadata: FE6 > F7 (0:0.6.1-4.fc6 > 0:0.6.1-3.fc7) quodlibet: FE5 > F7 (0:1.0-1.fc5 > 0:0.24-7.fc7) FE6 > F7 (0:1.0-1.fc6 > 0:0.24-7.fc7) rosegarden4: FE5 > F7 (0:1.5.1-1.fc5 > 0:1.4.0-1.fc7) FE6 > F7 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) rrdtool: FE5 > F7 (0:1.2.23-3.fc5 > 0:1.2.19-2.fc7) FE6 > F7 (0:1.2.23-3.fc6 > 0:1.2.19-2.fc7) shorewall: FE5 > F7 (0:3.4.3-1.fc5 > 0:3.4.2-1.fc7) FE6 > F7 (0:3.4.3-1.fc6 > 0:3.4.2-1.fc7) smb4k: FE5 > F7 (0:0.8.3-1.fc5 > 0:0.8.2-1.fc7) FE6 > F7 (0:0.8.3-1.fc6 > 0:0.8.2-1.fc7) sonata: FE6 > F7 (0:1.1-1.fc6 > 0:1.0.1-3.fc7) squirrelmail: FC6-updates > F7 (0:1.4.10a-1.fc6 > 0:1.4.9a-1.fc7) tcpick: FE5 > F7 (0:0.2.1-12.fc5 > 0:0.2.1-11.fc7) FE6 > F7 (0:0.2.1-12.fc6 > 0:0.2.1-11.fc7) transmission: FE6 > F7 (0:0.72-1.fc6 > 0:0.71-1.fc7) vdr-femon: FE6 > F7 (0:1.1.2-1.fc6 > 0:1.1.1-1.fc7) wavpack: FE5 > F7 (0:4.41-1.fc5 > 0:4.40-1.1.fc7) FE6 > F7 (0:4.41-1.fc6 > 0:4.40-1.1.fc7) wine: FE5 > F7 (0:0.9.36-2.fc5 > 0:0.9.36-1.fc7) FE6 > F7 (0:0.9.36-2.fc6 > 0:0.9.36-1.fc7) From jwboyer at jdub.homelinux.org Mon May 14 20:45:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 15:45:07 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179175371.19267.39.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> Message-ID: <1179175507.19267.42.camel@vader.jdub.homelinux.org> Out of the previous report, the following packages have a build sitting in dist-fc7 that would fix the broken upgrade path. Maintainers, please review this and submit a f7-final tag request to rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 final! josh asymptote-1.28-1.fc7 dist-fc7 jpo bitlbee-1.0.3-6.fc7 dist-fc7 robert cacti-0.8.6j-1.fc7 dist-fc7 mmcgrath cups-pdf-2.4.6-1.fc7 dist-fc7 remi cyphesis-0.5.12-1.fc7 dist-fc7 wart dap-server-3.7.4-3.fc7 dist-fc7 pertusus duplicity-0.4.2-7.fc7 dist-fc7 robert eclipse-cdt-3.1.2-3.fc7 dist-fc7 jkeating eggdrop-1.6.18-8.fc7 dist-fc7 robert em8300-0.16.2-1.fc7 dist-fc7 scop em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop fuse-2.6.5-1.fc7 dist-fc7 peter gallery2-2.2-0.4.svn20070506.fc7 dist-fc7 jwb gdal-1.4.1-3.fc7 dist-fc7 cbalint ghc-6.6.1-3.fc7 dist-fc7 bos gnash-0.7.2-2.fc7 dist-fc7 pertusus gtk+extra-2.1.1-4.fc7 dist-fc7 dionysos gtk2hs-0.9.11-4.fc7 dist-fc7 bos hdf-4.2r1-14.fc7 dist-fc7 orion htmldoc-1.8.27-2.fc7 dist-fc7 agoode koji-1.1-2.fc7 dist-fc7 jkeating libopm-0.1-4.20050731cvs.fc7 dist-fc7 robert librfid-0.1.0-3.1996svn.fc7 dist-fc7 kushal librsync-0.9.7-10.fc7 dist-fc7 robert m4-1.4.8-2.fc7 dist-fc7 jkeating mbuffer-20070502-1.fc7 dist-fc7 adalloz mimedefang-2.62-2.fc7 dist-fc7 robert moin-1.5.7-2.fc7 dist-fc7 thias opensc-0.11.2-2.fc7 dist-fc7 scop pan-0.129-1.fc7 dist-fc7 adalloz perl-CGI-Ex-2.12-1.fc7 dist-fc7 cweyl perl-Data-Alias-1.04-1.fc7 dist-fc7 cweyl perl-File-Copy-Recursive-0.33-2.fc7 dist-fc7 corsepiu perl-File-Next-0.40-1.fc7 dist-fc7 iburrell perl-JSON-1.14-1.fc7 dist-fc7 cweyl perl-Module-Refresh-0.13-1.fc7 dist-fc7 corsepiu perl-Module-ScanDeps-0.74-1.fc7 dist-fc7 jpo perl-Moose-0.21-1.fc7 dist-fc7 cweyl perl-Net-LibIDN-0.09-3.fc7 dist-fc7 robert perl-Pod-Strip-1.02-2.fc7 dist-fc7 jpo perl-POE-Component-Client-Keepalive-0.1000-1.fc7 dist-fc7 cweyl perl-POE-Component-IRC-5.29-1.fc7 dist-fc7 cweyl perl-POE-Component-SSLify-0.07-1.fc7 dist-fc7 cweyl perl-Test-Warn-0.10-1.fc7 dist-fc7 jpo perl-Text-Glob-0.08-1.fc7 dist-fc7 corsepiu perl-Want-0.14-1.fc7 dist-fc7 corsepiu php-idn-1.2-2.fc7 dist-fc7 robert php-pear-DB-DataObject-FormBuilder-1.0.0-0.5.RC7.fc7 dist-fc7 xulchris php-pear-MDB2-2.4.1-1.fc7 dist-fc7 xulchris php-pear-MDB2-Driver-mysql-1.4.1-1.fc7 dist-fc7 xulchris php-pear-Net-Socket-1.0.8-1.fc7 dist-fc7 remi php-pear-Structures-DataGrid-DataSource-DataObject-0.1.2-1.fc7 dist-fc7 xulchris quodlibet-1.0-1.fc7 dist-fc7 jcollie rrdtool-1.2.23-3.fc7 dist-fc7 jwilson shorewall-3.4.3-1.fc7 dist-fc7 robmv smb4k-0.8.3-1.fc7 dist-fc7 mgarski sonata-1.1-1.fc7 dist-fc7 ecik squirrelmail-1.4.10a-1.fc7 dist-fc7 mbacovsk tcpick-0.2.1-12.fc7 dist-fc7 robert transmission-0.72-1.fc7 dist-fc7 denis vdr-femon-1.1.2-1.fc7 dist-fc7 scop wavpack-4.41-1.fc7 dist-fc7 peter wine-0.9.36-2.fc7 dist-fc7 awjb From jwboyer at jdub.homelinux.org Mon May 14 20:46:46 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 15:46:46 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179175371.19267.39.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> Message-ID: <1179175606.19267.45.camel@vader.jdub.homelinux.org> These packages really do appear to have a broken upgrade path in Fedora 7. josh fortune-firefly-2.1.1-2.fc6 fe7-merge funtools-1.3.0-0.4.b29.fc7 fe7-merge libxml2-2.6.28-1 dist-fc7 python-kaa-metadata-0.6.1-3.fc7 fe7-merge rosegarden4-1.4.0-1.fc7 fe7-merge From jkeating at redhat.com Mon May 14 20:51:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 16:51:13 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179175507.19267.42.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> Message-ID: <200705141651.14036.jkeating@redhat.com> On Monday 14 May 2007 16:45:07 Josh Boyer wrote: > eclipse-cdt-3.1.2-3.fc7 ? ? ? ? ? ? ? ? ? dist-fc7 ? ? ? ? ? ? ?jkeating This was just the imported build, was never asked to be tagged by the person who did the build prior to the import. > koji-1.1-2.fc7 ? ? ? ? ? ? ? ? ? ? ? ? ? ?dist-fc7 ? ? ? ? ? ? ?jkeating We're actually working on a new koji that will supersede this. > m4-1.4.8-2.fc7 ? ? ? ? ? ? ? ? ? ? ? ? ? ?dist-fc7 ? ? ? ? ? ? ?jkeating This again was just the imported build. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Mon May 14 21:08:32 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 15 May 2007 00:08:32 +0300 Subject: Broken upgrade paths in F7 In-Reply-To: <1179175507.19267.42.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> Message-ID: <200705150008.33147.ville.skytta@iki.fi> On Monday 14 May 2007, Josh Boyer wrote: > Out of the previous report, the following packages have a build sitting > in dist-fc7 that would fix the broken upgrade path. > > Maintainers, please review this and submit a f7-final tag request to > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > final! [...] > em8300-0.16.2-1.fc7 dist-fc7 scop Tagged f7-final half an hour ago: http://koji.fedoraproject.org/koji/buildinfo?buildID=6353 Rawhide (download.fedora.redhat.com) seems to lag behind, the latest I see there is 0.16.2-0.1.rc1.fc7 > em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop Will be taken care of as soon as the required details about the F7 final kernel are available. > opensc-0.11.2-2.fc7 dist-fc7 scop Already tagged f7-final: http://koji.fedoraproject.org/koji/buildinfo?buildID=6297 Again, Rawhide lags behind f7-final; the newest I see there is 0.11.2-0.3.rc2.fc7 > vdr-femon-1.1.2-1.fc7 dist-fc7 scop Same story as above, tagged f7-final: - http://koji.fedoraproject.org/koji/buildinfo?buildID=6124 - Rawhide lags: 1.1.1-1.fc7 From jkeating at redhat.com Mon May 14 21:10:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 17:10:20 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) Message-ID: <200705141710.20460.jkeating@redhat.com> We're planning on entering "Deep Freeze" this Thursday. From that point on we'll only be accepting build tag requests for builds that are fixing release blockers. See http://fedoraproject.org/wiki/QA/ReleaseCriteria for current release criteria. At this time we will also be branching CVS for F-7. Builds from the devel/ branch will be given the dist-f8 tag and held until rawhide starts composing from dist-f8 (all dist-fc7 builds will be inherited by dist-f8 as well). Builds from the F-7/ branch will be given the dist-fc7-updates-candidate tag and can either wait for bodhi (the update tool) to become available to request as an update to Fedora 7, or if it is a release blocker be tagged with f7-final (after emailing rel-eng at fedoraproject.org) Mail will be sent prior to the CVS branching as there will be a small outage during the branching. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon May 14 21:16:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 May 2007 17:16:39 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <200705150008.33147.ville.skytta@iki.fi> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <200705150008.33147.ville.skytta@iki.fi> Message-ID: <200705141716.39777.jkeating@redhat.com> On Monday 14 May 2007 17:08:32 Ville Skytt? wrote: > Rawhide (download.fedora.redhat.com) seems to lag behind, the latest I see > there is 0.16.2-0.1.rc1.fc7 Rawhide compose was started on Friday, so that's where the package versions come from. A new rawhide compose will be started today and will pick up the tagging that has happened since. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjohnstn at redhat.com Mon May 14 21:28:09 2007 From: jjohnstn at redhat.com (Jeff Johnston) Date: Mon, 14 May 2007 17:28:09 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <200705141651.14036.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <200705141651.14036.jkeating@redhat.com> Message-ID: <4648D469.4070502@redhat.com> Jesse Keating wrote: > On Monday 14 May 2007 16:45:07 Josh Boyer wrote: >> eclipse-cdt-3.1.2-3.fc7 dist-fc7 jkeating > > This was just the imported build, was never asked to be tagged by the person > who did the build prior to the import. > I just made the request. -- Jeff J. From rc040203 at freenet.de Mon May 14 22:43:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 00:43:08 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179175507.19267.42.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> Message-ID: <1179182588.4735.374.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > Out of the previous report, the following packages have a build sitting > in dist-fc7 that would fix the broken upgrade path. > > Maintainers, please review this and submit a f7-final tag request to > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > final! All of my packages have been submitted the ordinary "make build" way either through plague or koji and are consistent in CVS. I don't consider it my job to sort out this broken release policy. Ralf From ajackson at redhat.com Mon May 14 23:21:27 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 14 May 2007 19:21:27 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179182588.4735.374.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> Message-ID: <1179184887.24664.64.camel@localhost.localdomain> On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: > On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > > Out of the previous report, the following packages have a build sitting > > in dist-fc7 that would fix the broken upgrade path. > > > > Maintainers, please review this and submit a f7-final tag request to > > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > > final! > All of my packages have been submitted the ordinary "make build" way > either through plague or koji and are consistent in CVS. I don't > consider it my job to sort out this broken release policy. I've suggested that releases should branch from devel before they actually release. It hasn't been implemented. I'm not sure why. - ajax From jwboyer at jdub.homelinux.org Tue May 15 00:38:20 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 19:38:20 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179182588.4735.374.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> Message-ID: <1179189501.19267.51.camel@vader.jdub.homelinux.org> On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: > On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > > Out of the previous report, the following packages have a build sitting > > in dist-fc7 that would fix the broken upgrade path. > > > > Maintainers, please review this and submit a f7-final tag request to > > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > > final! > All of my packages have been submitted the ordinary "make build" way > either through plague or koji and are consistent in CVS. I don't > consider it my job to sort out this broken release policy. Ok. Then you can deal with bug reports on your packages if/when users try to upgrade and they don't work. josh From sundaram at fedoraproject.org Tue May 15 00:45:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 06:15:22 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179189501.19267.51.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> Message-ID: <464902A2.60803@fedoraproject.org> Josh Boyer wrote: > On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: >> On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: >>> Out of the previous report, the following packages have a build sitting >>> in dist-fc7 that would fix the broken upgrade path. >>> >>> Maintainers, please review this and submit a f7-final tag request to >>> rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 >>> final! >> All of my packages have been submitted the ordinary "make build" way >> either through plague or koji and are consistent in CVS. I don't >> consider it my job to sort out this broken release policy. > > Ok. Then you can deal with bug reports on your packages if/when users > try to upgrade and they don't work. IMNSHO broken upgrades paths should be treated as release blockers. If package maintainers or others involved don't want to follow the process outlined and fix the packages, they should be pulled off before release. Rahul From jwboyer at jdub.homelinux.org Tue May 15 00:59:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 19:59:58 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <464902A2.60803@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> Message-ID: <1179190799.19267.66.camel@vader.jdub.homelinux.org> On Tue, 2007-05-15 at 06:15 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: > >> On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > >>> Out of the previous report, the following packages have a build sitting > >>> in dist-fc7 that would fix the broken upgrade path. > >>> > >>> Maintainers, please review this and submit a f7-final tag request to > >>> rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > >>> final! > >> All of my packages have been submitted the ordinary "make build" way > >> either through plague or koji and are consistent in CVS. I don't > >> consider it my job to sort out this broken release policy. > > > > Ok. Then you can deal with bug reports on your packages if/when users > > try to upgrade and they don't work. > > IMNSHO broken upgrades paths should be treated as release blockers. If > package maintainers or others involved don't want to follow the process > outlined and fix the packages, they should be pulled off before release. Pulled off how? They are already broken... We actually discussed whether broken upgrade paths were blockers today in the release meeting. There was unfortunately no decided outcome. Broken dependencies are however blockers. josh From sundaram at fedoraproject.org Tue May 15 01:30:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 07:00:09 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179190799.19267.66.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> Message-ID: <46490D21.6080703@fedoraproject.org> Josh Boyer wrote: > On Tue, 2007-05-15 at 06:15 +0530, Rahul Sundaram wrote: >> Josh Boyer wrote: >>> On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: >>>> On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: >>>>> Out of the previous report, the following packages have a build sitting >>>>> in dist-fc7 that would fix the broken upgrade path. >>>>> >>>>> Maintainers, please review this and submit a f7-final tag request to >>>>> rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 >>>>> final! >>>> All of my packages have been submitted the ordinary "make build" way >>>> either through plague or koji and are consistent in CVS. I don't >>>> consider it my job to sort out this broken release policy. >>> Ok. Then you can deal with bug reports on your packages if/when users >>> try to upgrade and they don't work. >> IMNSHO broken upgrades paths should be treated as release blockers. If >> package maintainers or others involved don't want to follow the process >> outlined and fix the packages, they should be pulled off before release. > > Pulled off how? They are already broken... Pull off the repository for Fedora 7 release. Please consider upgrade paths as release blockers. It is not just a matter of good quality packages. There will be security issues if packages are not updated properly. If you haven't been able to make this decision over IRC you can always discuss it on list. Rahul From jwboyer at jdub.homelinux.org Tue May 15 02:39:01 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 21:39:01 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <46490D21.6080703@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> Message-ID: <1179196741.19267.69.camel@vader.jdub.homelinux.org> On Tue, 2007-05-15 at 07:00 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Tue, 2007-05-15 at 06:15 +0530, Rahul Sundaram wrote: > >> Josh Boyer wrote: > >>> On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: > >>>> On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > >>>>> Out of the previous report, the following packages have a build sitting > >>>>> in dist-fc7 that would fix the broken upgrade path. > >>>>> > >>>>> Maintainers, please review this and submit a f7-final tag request to > >>>>> rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > >>>>> final! > >>>> All of my packages have been submitted the ordinary "make build" way > >>>> either through plague or koji and are consistent in CVS. I don't > >>>> consider it my job to sort out this broken release policy. > >>> Ok. Then you can deal with bug reports on your packages if/when users > >>> try to upgrade and they don't work. > >> IMNSHO broken upgrades paths should be treated as release blockers. If > >> package maintainers or others involved don't want to follow the process > >> outlined and fix the packages, they should be pulled off before release. > > > > Pulled off how? They are already broken... > > Pull off the repository for Fedora 7 release. Please consider upgrade How does that fix the upgrade path? It's no better than having an existing package with NVR less than FC/FE-6 functionally... What good does that do? > paths as release blockers. It is not just a matter of good quality > packages. There will be security issues if packages are not updated > properly. If you haven't been able to make this decision over IRC you > can always discuss it on list. It was mostly because we ran out of time as the meeting went for 2 hours. josh From sundaram at fedoraproject.org Tue May 15 02:47:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 08:17:18 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179196741.19267.69.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <1179196741.19267.69.camel@vader.jdub.homelinux.org> Message-ID: <46491F36.4020502@fedoraproject.org> Josh Boyer wrote: > How does that fix the upgrade path? It's no better than having an > existing package with NVR less than FC/FE-6 functionally... What good > does that do? It makes sure whatever packages that are in the repository are upgradeable. That's the standard that we should set for the Fedora repository. It gains us the trust of our end users on the quality of software that we include and it's conveys the message to the maintainers that their package simply won't be in the release unless they fix this. The update system should also refuse to publish packages when the EVR is broken. That's a pretty good incentive for everyone to do the right thing. Upgrade paths are broken when packages are orphaned too. I would consider any package where the maintainers haven't fix it to even upgrade from previous versions properly as effectively orphaned. Rahul From jwboyer at jdub.homelinux.org Tue May 15 03:02:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 14 May 2007 22:02:19 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <46491F36.4020502@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <1179196741.19267.69.camel@vader.jdub.homelinux.org> <46491F36.4020502@fedoraproject.org> Message-ID: <1179198139.19267.86.camel@vader.jdub.homelinux.org> On Tue, 2007-05-15 at 08:17 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > > How does that fix the upgrade path? It's no better than having an > > existing package with NVR less than FC/FE-6 functionally... What good > > does that do? > > It makes sure whatever packages that are in the repository are > upgradeable. That's the standard that we should set for the Fedora > repository. It gains us the trust of our end users on the quality of >From a functional standpoint, users won't see these via normal yum or pup/pirut interfaces. They would literally have to go look in the repository itself to even see the packages. So for quite a large portion of "end users" it doesn't convey anything at all. But I see where you're coming from. > software that we include and it's conveys the message to the maintainers > that their package simply won't be in the release unless they fix this. In general, perhaps. But right now people are still getting used to the process in the merged world. Give them time. Being overly draconian about it won't win anyone over. Perhaps other maintainers will volunteer to fix things even. /me tries to remember some saying about catching something with honey instead of something that tastes bad... or something. > The update system should also refuse to publish packages when the EVR is > broken. That's a pretty good incentive for everyone to do the right thing. Agreed. I hope bodhi does this, but I have no idea. > Upgrade paths are broken when packages are orphaned too. I would > consider any package where the maintainers haven't fix it to even > upgrade from previous versions properly as effectively orphaned. I think you're getting slightly ahead of yourself. Let us see what the overall response to this thread is and deal with the remainders in a day or two. josh From j.w.r.degoede at hhs.nl Tue May 15 05:54:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 15 May 2007 07:54:27 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705141710.20460.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> Message-ID: <46494B13.1070500@hhs.nl> Jesse Keating wrote: > We're planning on entering "Deep Freeze" this Thursday. From that point on > we'll only be accepting build tag requests for builds that are fixing release > blockers. See http://fedoraproject.org/wiki/QA/ReleaseCriteria for current > release criteria. > > At this time we will also be branching CVS for F-7. Builds from the devel/ > branch will be given the dist-f8 tag and held until rawhide starts composing > from dist-f8 (all dist-fc7 builds will be inherited by dist-f8 as well). > Builds from the F-7/ branch will be given the dist-fc7-updates-candidate tag > and can either wait for bodhi (the update tool) to become available to > request as an update to Fedora 7, or if it is a release blocker be tagged > with f7-final (after emailing rel-eng at fedoraproject.org) > What will be the procedure for the always existing trickle of new packages during the deep freeze? And what will be the procedure for new packages once F7 is released? Regards, Hans From mtasaka at ioa.s.u-tokyo.ac.jp Tue May 15 06:38:39 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 15 May 2007 15:38:39 +0900 Subject: koji rebuild refuses due to sslv3 certificate expire Message-ID: <4649556F.90100@ioa.s.u-tokyo.ac.jp> Hello. I want to send a build queue of jd to koji, however it is refused with returning error messages below: --------------------------------------------------- [tasaka1 at localhost devel]$ LANG=C make build : [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] make: *** [koji] Error 1 --------------------------------------------------- I even re-downloaded a new client certificate and now my ~/.fedora.cert says: --------------------------------------------------- Issuer: C=US, ST=North Carolina, L=Raleigh, O=Fedora Project, OU=Upload Files, CN=cvs.fedora.redhat.com/emailAddress=webmaster at fedora.redhat.com Validity Not Before: May 15 05:36:04 2007 GMT Not After : May 14 05:36:04 2008 GMT Subject: C=US, ST=North Carolina, O=Fedora Project, OU=Mamoru Tasaka, CN=mtasaka/emailAddress=mtasaka at ioa.s.u-tokyo.ac.jp --------------------------------------------------- What can I do for this failure? Mamoru From bugs.michael at gmx.net Tue May 15 07:26:10 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 09:26:10 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <46490D21.6080703@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> Message-ID: <20070515092610.6d0cae6b.bugs.michael@gmx.net> On Tue, 15 May 2007 07:00:09 +0530, Rahul Sundaram wrote: > >> IMNSHO broken upgrades paths should be treated as release blockers. If > >> package maintainers or others involved don't want to follow the process > >> outlined and fix the packages, they should be pulled off before release. > > > > Pulled off how? They are already broken... > > Pull off the repository for Fedora 7 release. Please consider upgrade > paths as release blockers. Avoid broken upgrade paths like the plague. They bear a big risk of breaking Yum dist-upgrades, which in turn give burnt users a good opportunity to bash Fedora. Any problems with the repositories and package updates result in bad publicity. It's worse enough already that some mirrors sit on half-mirrored metadata for several days. From fedora at leemhuis.info Tue May 15 07:52:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 May 2007 09:52:03 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515092610.6d0cae6b.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> Message-ID: <464966A3.9090101@leemhuis.info> On 15.05.2007 09:26, Michael Schwendt wrote: > On Tue, 15 May 2007 07:00:09 +0530, Rahul Sundaram wrote: > >>>> IMNSHO broken upgrades paths should be treated as release blockers. If >>>> package maintainers or others involved don't want to follow the process >>>> outlined and fix the packages, they should be pulled off before release. >>> Pulled off how? They are already broken... >> Pull off the repository for Fedora 7 release. Please consider upgrade >> paths as release blockers. > Avoid broken upgrade paths like the plague. They bear a big risk of > breaking Yum dist-upgrades, which in turn give burnt users a good > opportunity to bash Fedora. [...] Agreed, but that's a general problem, and not that specific to release time as the upgrade path against the released F7 might break soon after F7 was released anyway. Example: F7 release time has this in the repos: * F6 repo: foo-1.1-4.fc6.i386.rpm * F7 repo and on the media: foo-1.1-4.fc7.i386.rpm two weeks later foo got a update: * F6 repo: foo-1.1-6.fc6.i386.rpm * F7 repo: foo-1.1-6.fc7.i386.rpm The F7 isos of course still has foo-1.1-4.fc7.i386.rpm; so if someone has a full up2date F6-system two weeks after F7 got released and then does the upgrade from F6 to F7 with the media he won't get foo updated anyway. He'll get it with the first "yum update" after the dist upgrade. So we need to *always* make sure the upgrade path is proper, not only at release time. As such I think Rahul is shooting way over the top with pulling them from the repo, as that creates even more trouble for users. CU thl From bugs.michael at gmx.net Tue May 15 08:26:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 10:26:55 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <464966A3.9090101@leemhuis.info> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> Message-ID: <20070515102655.41d06806.bugs.michael@gmx.net> On Tue, 15 May 2007 09:52:03 +0200, Thorsten Leemhuis wrote: > > Avoid broken upgrade paths like the plague. They bear a big risk of > > breaking Yum dist-upgrades, which in turn give burnt users a good > > opportunity to bash Fedora. [...] > > Agreed, but that's a general problem, and not that specific to release > time as the upgrade path against the released F7 might break soon after > F7 was released anyway. Example: Yes, known thing. A better example increases %version and/or introduces a new ABI. ;o) Firstboot fun. > So we need to *always* make sure the upgrade path is proper, not only at > release time. That's only easy as long as only %release is updated for old dists. When old dists get %version upgrades, there is no solution other than pure online dist-upgrades. From fedora at leemhuis.info Tue May 15 08:43:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 May 2007 10:43:57 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515102655.41d06806.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <20070515102655.41d06806.bugs.michael@gmx.net> Message-ID: <464972CD.8020904@leemhuis.info> On 15.05.2007 10:26, Michael Schwendt wrote: > On Tue, 15 May 2007 09:52:03 +0200, Thorsten Leemhuis wrote: > >>> Avoid broken upgrade paths like the plague. They bear a big risk of >>> breaking Yum dist-upgrades, which in turn give burnt users a good >>> opportunity to bash Fedora. [...] >> Agreed, but that's a general problem, and not that specific to release >> time as the upgrade path against the released F7 might break soon after >> F7 was released anyway. Example: > Yes, known thing. Well, I'm sure you and some other know that, but I got the impression that some people forgot about that or are not aware of it, so I thought it was worth pointing out again :-) > A better example increases %version and/or introduces a > new ABI. ;o) Firstboot fun. Yeah. /me wonders what anaconda does in this case >> So we need to *always* make sure the upgrade path is proper, not only at >> release time. > That's only easy as long as only %release is updated for old dists. > When old dists get %version upgrades, there is no solution other than > pure online dist-upgrades. Likely. CU thl From paul at city-fan.org Tue May 15 11:19:39 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 15 May 2007 12:19:39 +0100 Subject: koji rebuild refuses due to sslv3 certificate expire In-Reply-To: <4649556F.90100@ioa.s.u-tokyo.ac.jp> References: <4649556F.90100@ioa.s.u-tokyo.ac.jp> Message-ID: <4649974B.1010002@city-fan.org> Mamoru Tasaka wrote: > Hello. > > I want to send a build queue of jd to koji, however > it is refused with returning error messages below: > > --------------------------------------------------- > [tasaka1 at localhost devel]$ LANG=C make build > : [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate > expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] > make: *** [koji] Error 1 > --------------------------------------------------- > > I even re-downloaded a new client certificate and > now my ~/.fedora.cert says: > --------------------------------------------------- > Issuer: C=US, ST=North Carolina, L=Raleigh, O=Fedora Project, OU=Upload Files, > CN=cvs.fedora.redhat.com/emailAddress=webmaster at fedora.redhat.com > Validity > Not Before: May 15 05:36:04 2007 GMT > Not After : May 14 05:36:04 2008 GMT > Subject: C=US, ST=North Carolina, O=Fedora Project, OU=Mamoru Tasaka, > CN=mtasaka/emailAddress=mtasaka at ioa.s.u-tokyo.ac.jp > --------------------------------------------------- > > What can I do for this failure? I had this problem over the weekend too. Koji does not use ~/.fedora.cert directly, it uses ~/.koji/client.crt, which is copied from ~/.fedora.cert when you run fedora-packager-setup.sh, if there is not already a ~/.koji/client.crt present. It won't overwrite an existing cert, even if it has expired. I just did: $ rm -rf ~/.koji $ fedora-packager-setup.sh and all was well again. Paul. From mtasaka at ioa.s.u-tokyo.ac.jp Tue May 15 11:32:41 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 15 May 2007 20:32:41 +0900 Subject: [SOLVED] Re: koji rebuild refuses due to sslv3 certificate expire In-Reply-To: <4649974B.1010002@city-fan.org> References: <4649556F.90100@ioa.s.u-tokyo.ac.jp> <4649974B.1010002@city-fan.org> Message-ID: <46499A59.3020806@ioa.s.u-tokyo.ac.jp> Paul Howarth wrote, at 05/15/2007 08:19 PM +9:00: > Mamoru Tasaka wrote: >> Hello. >> >> I want to send a build queue of jd to koji, however >> it is refused with returning error messages below: >> >> I even re-downloaded a new client certificate >> What can I do for this failure? > > I had this problem over the weekend too. Koji does not use > ~/.fedora.cert directly, it uses ~/.koji/client.crt, which is copied > from ~/.fedora.cert when you run fedora-packager-setup.sh, if there is > not already a ~/.koji/client.crt present. It won't overwrite an existing > cert, even if it has expired. I just did: > > $ rm -rf ~/.koji > $ fedora-packager-setup.sh > > and all was well again. > > Paul. Oh, it did work. Thank you!! Mamoru From rc040203 at freenet.de Tue May 15 13:23:04 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 15:23:04 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179189501.19267.51.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> Message-ID: <1179235385.4735.474.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 19:38 -0500, Josh Boyer wrote: > On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: > > On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > > > Out of the previous report, the following packages have a build sitting > > > in dist-fc7 that would fix the broken upgrade path. > > > > > > Maintainers, please review this and submit a f7-final tag request to > > > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > > > final! > > All of my packages have been submitted the ordinary "make build" way > > either through plague or koji and are consistent in CVS. I don't > > consider it my job to sort out this broken release policy. > > Ok. Then you can deal with bug reports on your packages if/when users > try to upgrade and they don't work. When will you understand that I did apply the same procedures as with all Fedora releases before - You report actually points out regressions koji imposes on community maintainers. I really don't have a problem in orphaning these packages, because my interest in continuing to struggle with packages in Fedora drops by the minute. From jwboyer at jdub.homelinux.org Tue May 15 13:43:53 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 08:43:53 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179235385.4735.474.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> Message-ID: <1179236633.3084.51.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 15:23 +0200, Ralf Corsepius wrote: > On Mon, 2007-05-14 at 19:38 -0500, Josh Boyer wrote: > > On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: > > > On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > > > > Out of the previous report, the following packages have a build sitting > > > > in dist-fc7 that would fix the broken upgrade path. > > > > > > > > Maintainers, please review this and submit a f7-final tag request to > > > > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > > > > final! > > > All of my packages have been submitted the ordinary "make build" way > > > either through plague or koji and are consistent in CVS. I don't > > > consider it my job to sort out this broken release policy. > > > > Ok. Then you can deal with bug reports on your packages if/when users > > try to upgrade and they don't work. > > When will you understand that I did apply the same procedures as with > all Fedora releases before - You report actually points out regressions > koji imposes on community maintainers. We've been over this before Ralf. Things change. It's not a regression, it's a change in workflow. Now I can understand that it is 1) different, 2) more burden than the old process, and 3) perhaps confusing. If you're confused about something, ask some questions. I'd be happy to answer them. As for the additional burden, it's really only present during the Freeze time, which happens to be now. I honestly believe this is a good thing in the long run. > I really don't have a problem in orphaning these packages, because my > interest in continuing to struggle with packages in Fedora drops by the > minute. If you were to do so, that would be quite sad. It takes a simple email to get these packages into f7-final and thus far you are the only person to publicly refuse to do so. To lose a valued contributor over the matter of an email would be sad indeed. And no, rel-eng cannot just tag them for you. We need some kind of input from the package maintainer as to whether they're safe to enable and make sure they don't break dependencies, etc. josh From rc040203 at freenet.de Tue May 15 13:56:28 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 15:56:28 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179236633.3084.51.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> Message-ID: <1179237388.4735.486.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 08:43 -0500, Josh Boyer wrote: > On Tue, 2007-05-15 at 15:23 +0200, Ralf Corsepius wrote: > > On Mon, 2007-05-14 at 19:38 -0500, Josh Boyer wrote: > > > On Tue, 2007-05-15 at 00:43 +0200, Ralf Corsepius wrote: > > > > On Mon, 2007-05-14 at 15:45 -0500, Josh Boyer wrote: > > > > > Out of the previous report, the following packages have a build sitting > > > > > in dist-fc7 that would fix the broken upgrade path. > > > > > > > > > > Maintainers, please review this and submit a f7-final tag request to > > > > > rel-eng at fedoraproject.org if these builds are suitable for Fedora 7 > > > > > final! > > > > All of my packages have been submitted the ordinary "make build" way > > > > either through plague or koji and are consistent in CVS. I don't > > > > consider it my job to sort out this broken release policy. > > > > > > Ok. Then you can deal with bug reports on your packages if/when users > > > try to upgrade and they don't work. > > > > When will you understand that I did apply the same procedures as with > > all Fedora releases before - You report actually points out regressions > > koji imposes on community maintainers. > > We've been over this before Ralf. Things change. It's not a > regression, it's a change in workflow. It's an undocumented insane regression in workflow and a mistake of release engineering - IMO, it's yet another case of RH having out-ruling a once functional practice and replaced it with something not helpful to external contributors. > > I really don't have a problem in orphaning these packages, because my > > interest in continuing to struggle with packages in Fedora drops by the > > minute. > > If you were to do so, that would be quite sad. You still have your chances to change your workflow to something sane, ... or at least to document it. Right now koji doesn't have any usable documentation nor is the workflow you are referring to documented anywhere - Not even your contained an URL to this documentation. I.e. I consider all these EVR breakages rel-eng's fault and it to be their job to handle them - period. > And no, rel-eng cannot just tag them for you. We need some kind of > input from the package maintainer as to whether they're safe to enable > and make sure they don't break dependencies, etc. ... because your work-flow is broken. You guys should have branched rawhide before the freeze (BTW: you guy now also seem to have inconsistencies been rawhide and the buildsystem. Yesterday, I was facing packages which built in rawhide but failed in the buildsystem). From mitr at redhat.com Tue May 15 13:59:55 2007 From: mitr at redhat.com (Miloslav Trmac) Date: Tue, 15 May 2007 15:59:55 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179237388.4735.486.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> Message-ID: <4649BCDB.50202@redhat.com> Ralf Corsepius napsal(a): > Right now koji doesn't have any usable documentation nor is the workflow > you are referring to documented anywhere The freeze has nothing to do with koji. We could have used koji without having the freeze. Mirek From jwboyer at jdub.homelinux.org Tue May 15 14:12:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 09:12:06 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179237388.4735.486.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> Message-ID: <1179238326.3084.64.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 15:56 +0200, Ralf Corsepius wrote: > > > I really don't have a problem in orphaning these packages, because my > > > interest in continuing to struggle with packages in Fedora drops by the > > > minute. > > > > If you were to do so, that would be quite sad. > > You still have your chances to change your workflow to something > sane, ... or at least to document it. http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy and http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO Those have been sent out multiple times. > Right now koji doesn't have any usable documentation nor is the workflow You keep saying that, but what documentation are you looking for? From a maintainers standpoint, all you need to do is 'make build' and follow the DevelFreezePolicy. > you are referring to documented anywhere - Not even your contained an > URL to this documentation. We've sent the above URLs multiple times to this list. > I.e. I consider all these EVR breakages rel-eng's fault and it to be > their job to handle them - period. If that is your final answer, we will have to come up with some way of dealing with those packages. Rahul is asking for them to be pulled from the repositories. I had hoped to avoid things like that since it doesn't really fix anything. Are you effectively orphaning your packages? > > And no, rel-eng cannot just tag them for you. We need some kind of > > input from the package maintainer as to whether they're safe to enable > > and make sure they don't break dependencies, etc. > ... because your work-flow is broken. Our lack of knowledge about every package that exists has little to do with workflow. > You guys should have branched rawhide before the freeze (BTW: you guy That very well could be. But the procedure would have still been the same. > now also seem to have inconsistencies been rawhide and the buildsystem. > Yesterday, I was facing packages which built in rawhide but failed in > the buildsystem). Which and how did they fail? josh From jkeating at redhat.com Tue May 15 14:14:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 10:14:34 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179237388.4735.486.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> Message-ID: <200705151014.40688.jkeating@redhat.com> On Tuesday 15 May 2007 09:56:28 Ralf Corsepius wrote: > undocumented http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy Really. Try to keep up Ralf. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue May 15 14:16:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 10:16:27 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <46494B13.1070500@hhs.nl> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> Message-ID: <200705151016.27873.jkeating@redhat.com> On Tuesday 15 May 2007 01:54:27 Hans de Goede wrote: > What will be the procedure for the always existing trickle of new packages > during the deep freeze? They will get the devel/ branch for free, which directs builds to dist-f8. The maintainer would have to request branches for existing releases as always, FC-6, F-7, EPEL?. The F-7 build will go toward the dist-fc7-updates-candidate tag, and the package would have to be issued as an update to Fedora 7. Surprise, new package announcements, what an awesome thing! > And what will be the procedure for new packages once F7 is released? See above. They go out as an update to Fedora 7 and thus get a nice announcement and such. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Tue May 15 14:20:55 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 15 May 2007 09:20:55 -0500 (CDT) Subject: Broken upgrade paths in F7 In-Reply-To: <1179237388.4735.486.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> Message-ID: On Tue, 15 May 2007, Ralf Corsepius wrote: > On Tue, 2007-05-15 at 08:43 -0500, Josh Boyer wrote: >> We've been over this before Ralf. Things change. It's not a >> regression, it's a change in workflow. > > It's an undocumented insane regression in workflow and a mistake of > release engineering - IMO, it's yet another case of RH having out-ruling > a once functional practice and replaced it with something not helpful to > external contributors. Not helpful to external contributors? Let me pick that claim apart. 1. Us external contributors can now sign up to work on former-Core packages. 2. Former-Core packages can now BR/link against former-Extras packages. 3. Things are no longer hidden behind Red Hat's internal, at-least-somewhat-proprietary buildsystem. Everything's in the open. 4. I know at least one non-employee of Red Hat works on improving and managing Koji (i.e., this isn't part of the Grand Red Hat Conspiracy). 5. The development freezes have been done before, they just were enforced quite poorly in Extras. Downside: More restrictions for former-Extras. Upside: Extras packages are no longer "second-class citizens." Need I continue? Jima (also a non-RH employee) From katzj at redhat.com Tue May 15 14:50:36 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 15 May 2007 10:50:36 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179184887.24664.64.camel@localhost.localdomain> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179184887.24664.64.camel@localhost.localdomain> Message-ID: <1179240637.29594.2.camel@erebor.boston.redhat.com> On Mon, 2007-05-14 at 19:21 -0400, Adam Jackson wrote: > I've suggested that releases should branch from devel before they > actually release. It hasn't been implemented. I'm not sure why. Because (as the discussion showed :-), that has other downsides. Really, we need an easy way for maintainers to do branching themselves so that the branching can be done at the most suitable point on a package by package basis. If you're interested in helping with the infrastructure side of this, we'd love to have some help on that front. Jeremy From Jochen at herr-schmitt.de Tue May 15 14:53:53 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 15 May 2007 16:53:53 +0200 Subject: Request for comaintainers Message-ID: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm search comaintainsers for this packages: - - aplus-fsf - - blender - - crossvc - - gnu-smalltalk - - gprolog - - highlight - - inadyn - - kyum - - lightning - - luma - - pdftk - - steghide - - stellarium - - suck As a second question, what I have to do, that comaintainers can recieve bugzilla messages and do builds for the packages? Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGScmcT2AHK6txfgwRAvkEAJ9L6u/wAuAsInWHK8oze4UPGHLMGgCePBaH A/CMl4ur6HIazZNYS0vufrw= =1+Av -----END PGP SIGNATURE----- From rc040203 at freenet.de Tue May 15 14:21:37 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 16:21:37 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705151014.40688.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> <200705151014.40688.jkeating@redhat.com> Message-ID: <1179238898.4735.500.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 10:14 -0400, Jesse Keating wrote: > On Tuesday 15 May 2007 09:56:28 Ralf Corsepius wrote: > > undocumented > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > Really. Really, stop cheating. No word on release tags, no word on how to interface this into koji, no word on the freeze breaking "make build", ... > Try to keep up Ralf. I have decided to take a break from Fedora until things have settled. From jwboyer at jdub.homelinux.org Tue May 15 15:02:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 10:02:59 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179238898.4735.500.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> <200705151014.40688.jkeating@redhat.com> <1179238898.4735.500.camel@mccallum.corsepiu.local> Message-ID: <1179241379.3084.75.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 16:21 +0200, Ralf Corsepius wrote: > On Tue, 2007-05-15 at 10:14 -0400, Jesse Keating wrote: > > On Tuesday 15 May 2007 09:56:28 Ralf Corsepius wrote: > > > undocumented > > > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > > Really. > Really, stop cheating. > > No word on release tags, > no word on how to interface this into koji, > no word on the freeze breaking "make build", > ... > > Try to keep up Ralf. > > I have decided to take a break from Fedora until things have settled. Are you orphaning your packages then? I just want things to be as clear as possible to avoid any confusion. josh From jkeating at redhat.com Tue May 15 15:04:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 11:04:18 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179238898.4735.500.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705151014.40688.jkeating@redhat.com> <1179238898.4735.500.camel@mccallum.corsepiu.local> Message-ID: <200705151104.18296.jkeating@redhat.com> On Tuesday 15 May 2007 10:21:37 Ralf Corsepius wrote: > > Really. > > Really, stop cheating. > > No word on release tags, What word are you looking for here? Maybe the overall view http://fedoraproject.org/wiki/ReleaseEngineering/Overview ? > no word on how to interface this into koji, Why do you care, you're not the one doing the tagging. > no word on the freeze breaking "make build", > ... I don't even know what you mean by that sentence. > > > ? Try to keep up Ralf. > > I have decided to take a break from Fedora until things have settled. Will you be properly orphaning your packages? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue May 15 15:04:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 17:04:54 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179240637.29594.2.camel@erebor.boston.redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179184887.24664.64.camel@localhost.localdomain> <1179240637.29594.2.camel@erebor.boston.redhat.com> Message-ID: <1179241494.4735.519.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 10:50 -0400, Jeremy Katz wrote: > On Mon, 2007-05-14 at 19:21 -0400, Adam Jackson wrote: > > I've suggested that releases should branch from devel before they > > actually release. It hasn't been implemented. I'm not sure why. > > Because (as the discussion showed :-), that has other downsides. Really, I don't buy this. If you had taken a snapshot of FC7 and used this as basis for the DVDs (aka freeze), simultaneously to forking rawhide, all this discussion would have been mood. FC7 updates (after "freeze", before "official launch") could have gone to FC7/updates without interrupting rel-engs work on the DVDs nor would rel-eng's work have interfered with "maintainer's work" (as it now does). The only thing which would have changed was "the release's repos being exposed" to the public before an official "launch" (i.e. a marketing event). > Really, we need an easy way for maintainers to do branching themselves > so that the branching can be done at the most suitable point on a > package by package basis. I also don't see this. At the very moment you fork rawhide and , you decouple rawhide and release, i.e. maintainers can chose which version to push into which release version. ATM, you block "upstream" due to the "freeze". This is the working principle how FE had worked ever since it existed. Ralf From pertusus at free.fr Tue May 15 14:58:59 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 16:58:59 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179236633.3084.51.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> Message-ID: <20070515145859.GD2815@free.fr> On Tue, May 15, 2007 at 08:43:53AM -0500, Josh Boyer wrote: > > Now I can understand that it is 1) different, 2) more burden than the > old process, and 3) perhaps confusing. If you're confused about > something, ask some questions. I'd be happy to answer them. > > As for the additional burden, it's really only present during the Freeze > time, which happens to be now. I honestly believe this is a good thing > in the long run. I think that there should be something done for the freeze and releases, but I am not happy with the current state, because it adds burden without real gain. It seems to me that the contributors should tag themselves what they think belongs to the release, and release engineer should only veto things they find unwise and/or ask on fedora-devel or fedora-maintainers for clarifications for packages they'd like to veto. How many tag to the release were rejected? -- Pat From pertusus at free.fr Tue May 15 15:00:20 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 17:00:20 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151016.27873.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> Message-ID: <20070515150020.GE2815@free.fr> On Tue, May 15, 2007 at 10:16:27AM -0400, Jesse Keating wrote: > > See above. They go out as an update to Fedora 7 and thus get a nice > announcement and such. Will there be a way to short-circuit the announcement and just update, like it was possible before? -- Pat From jwboyer at jdub.homelinux.org Tue May 15 15:10:42 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 10:10:42 -0500 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515150020.GE2815@free.fr> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> Message-ID: <1179241842.3084.77.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > On Tue, May 15, 2007 at 10:16:27AM -0400, Jesse Keating wrote: > > > > See above. They go out as an update to Fedora 7 and thus get a nice > > announcement and such. > > Will there be a way to short-circuit the announcement and just update, > like it was possible before? Why would you want to do that? It gives the end users some idea as to why the package was updated... josh From ssorce at redhat.com Tue May 15 15:12:06 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 15 May 2007 11:12:06 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179240637.29594.2.camel@erebor.boston.redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179184887.24664.64.camel@localhost.localdomain> <1179240637.29594.2.camel@erebor.boston.redhat.com> Message-ID: <1179241926.7663.4.camel@willson> On Tue, 2007-05-15 at 10:50 -0400, Jeremy Katz wrote: > On Mon, 2007-05-14 at 19:21 -0400, Adam Jackson wrote: > > I've suggested that releases should branch from devel before they > > actually release. It hasn't been implemented. I'm not sure why. > > Because (as the discussion showed :-), that has other downsides. > Really, we need an easy way for maintainers to do branching themselves > so that the branching can be done at the most suitable point on a > package by package basis. If you're interested in helping with the > infrastructure side of this, we'd love to have some help on that front. Wouldn't it make sense to pre-branch F-8 right after development is started? There the developer can put stable versions (if he wish). It will not be used for Rawhide which will continue to be devel, but as a way to put packages the developer is more confident in. It will be probably little used until we are close to release, but being there already removes any problem about creation permissions. Once the freeze is close people will be requested to put the latest stable package from devel to F-8 and the test versions will fetch from there and not from devel. This will also allow the release managers to block committing to the F-8 branch at freeze, and we could think of a mechanism to unblock on a case by case basis after request to rel-eng@ Simo. From jkeating at redhat.com Tue May 15 15:13:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 11:13:07 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515145859.GD2815@free.fr> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179236633.3084.51.camel@zod.rchland.ibm.com> <20070515145859.GD2815@free.fr> Message-ID: <200705151113.07471.jkeating@redhat.com> On Tuesday 15 May 2007 10:58:59 Patrice Dumas wrote: > I think that there should be something done for the freeze and releases, > but I am not happy with the current state, because it adds burden > without real gain. It seems to me that the contributors should tag > themselves what they think belongs to the release, and release engineer > should only veto things they find unwise and/or ask on fedora-devel or > fedora-maintainers for clarifications for packages they'd like to veto. > > How many tag to the release were rejected? To be perfectly honest, I'm not completely happy with this process for the final freeze either. This was an experiment for the Fedora 7 release, and it went really well for the test release freezes. I agree that the final freeze should be done differently, however I didn't want to change it at this point. Asking how many were rejected isn't quite fair. It's not the people who are asking for tagging that I'm concerned with, it's the people who just don't realize we're in a freeze and happily drop in a soname bump that breaks a ton of packages or other such acts without noticing that we're in a freeze and doing such can cause problems with the release. This has happened in the past, I'm not just being overly paranoid. I very much want there to be less overhead, and I welcome any effort into the workflow that gets us there, but at the same time we have to be able to manage a freeze and have control over what gets in and what doesn't. Striking the balance is very difficult to do. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Tue May 15 15:13:31 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 15 May 2007 11:13:31 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179240637.29594.2.camel@erebor.boston.redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179184887.24664.64.camel@localhost.localdomain> <1179240637.29594.2.camel@erebor.boston.redhat.com> Message-ID: <1179242011.16274.38.camel@localhost.localdomain> On Tue, 2007-05-15 at 10:50 -0400, Jeremy Katz wrote: > On Mon, 2007-05-14 at 19:21 -0400, Adam Jackson wrote: > > I've suggested that releases should branch from devel before they > > actually release. It hasn't been implemented. I'm not sure why. > > Because (as the discussion showed :-), that has other downsides. > Really, we need an easy way for maintainers to do branching themselves > so that the branching can be done at the most suitable point on a > package by package basis. If you're interested in helping with the > infrastructure side of this, we'd love to have some help on that front. Clearly I missed that discussion. In my world it's no different from having to do dual commits for master and release branches in an upstream project, or having to build something into both devel and FC6 for updates. This is a thing I'm already used to; I don't see why OS release preparation should require I use a different workflow. (Although I would love a cli interface to the updates system, as the current one is needlessly hard to automate.) I don't know what's involved on the CVS server side for branch creation, but I suspect the UI for this is: if you're on the devel branch, you may issue 'make release-branch' to create the F7 branch, which is initially populated from the revision currently in CVS. This sounds really close to what we do internally for embargo branch creation, modulo the whole non-propagation thing. - ajax From jkeating at redhat.com Tue May 15 15:14:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 11:14:35 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515150020.GE2815@free.fr> References: <200705141710.20460.jkeating@redhat.com> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> Message-ID: <200705151114.35814.jkeating@redhat.com> On Tuesday 15 May 2007 11:00:20 Patrice Dumas wrote: > Will there be a way to short-circuit the announcement and just update, > like it was possible before? No, as that is a very poor end user experience. Here I've got 40 updates, without a clue as to why these updates exist and why I should use bandwidth to pull them down. Updates without announcements / reasons is just chucking grenades over the wall. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Tue May 15 15:15:36 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 15 May 2007 10:15:36 -0500 (CDT) Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179241842.3084.77.camel@zod.rchland.ibm.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179241842.3084.77.camel@zod.rchland.ibm.com> Message-ID: On Tue, 15 May 2007, Josh Boyer wrote: > On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: >> Will there be a way to short-circuit the announcement and just update, >> like it was possible before? > > Why would you want to do that? It gives the end users some idea as to > why the package was updated... Some announcements are just hard to find the right words for. "Snuck malware into the package" really doesn't have the right ring to it. ;-) Jima From rc040203 at freenet.de Tue May 15 14:32:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 16:32:14 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <4649BCDB.50202@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> <4649BCDB.50202@redhat.com> Message-ID: <1179239534.4735.504.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 15:59 +0200, Miloslav Trmac wrote: > Ralf Corsepius napsal(a): > > Right now koji doesn't have any usable documentation nor is the workflow > > you are referring to documented anywhere > The freeze has nothing to do with koji. It has. 1. koji had not been usable since a couple of days ago. It took me ca. 2 days to get it going at all and am still not satisfied with it. 2. In FE a "make build" had built packages into "current", and not into some special tag. > We could have used koji without > having the freeze. You should better have done it. Probably a lot of the issues users are facing now would not have occurred. Ralf From bugs.michael at gmx.net Tue May 15 15:48:13 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 17:48:13 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179236633.3084.51.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> Message-ID: <20070515174813.05d3929d.bugs.michael@gmx.net> On Tue, 15 May 2007 08:43:53 -0500, Josh Boyer wrote: [Ralf] > > When will you understand that I did apply the same procedures as with > > all Fedora releases before - You report actually points out regressions > > koji imposes on community maintainers. > > We've been over this before Ralf. Things change. It's not a > regression, it's a change in workflow. The change in workflow causes regression. > If you were to do so, that would be quite sad. It takes a simple email > to get these packages into f7-final and thus far you are the only person > to publicly refuse to do so. To lose a valued contributor over the > matter of an email would be sad indeed. You don't know that yet. Many other contributors have not even used koji yet. Others don't know that FC <= 4 is EOL. Others have done "make built" without asking for a tag. You guess that they don't want the tag. But it is likely they just don't know about the extra burden yet. From bugs.michael at gmx.net Tue May 15 15:51:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 17:51:33 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179237388.4735.486.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> Message-ID: <20070515175133.783e5f32.bugs.michael@gmx.net> On Tue, 15 May 2007 15:56:28 +0200, Ralf Corsepius wrote: > I.e. I consider all these EVR breakages rel-eng's fault and it to be > their job to handle them - period. Hehe, I hope there will also be more unannounced broken deps in the builds such as the ones I've had to reject/exclude again and again recently. Unfortunately, we couldn't do fully automated checks, so when somebody else pushed, some bad updates slipped through. Sorry for that, btw. From jwboyer at jdub.homelinux.org Tue May 15 15:56:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 10:56:06 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515174813.05d3929d.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <20070515174813.05d3929d.bugs.michael@gmx.net> Message-ID: <1179244566.3084.86.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 17:48 +0200, Michael Schwendt wrote: > On Tue, 15 May 2007 08:43:53 -0500, Josh Boyer wrote: > > [Ralf] > > > When will you understand that I did apply the same procedures as with > > > all Fedora releases before - You report actually points out regressions > > > koji imposes on community maintainers. > > > > We've been over this before Ralf. Things change. It's not a > > regression, it's a change in workflow. > > The change in workflow causes regression. If you'd like to view it that way, ok. Except regression can be fixed by adapting to the change. > > If you were to do so, that would be quite sad. It takes a simple email > > to get these packages into f7-final and thus far you are the only person > > to publicly refuse to do so. To lose a valued contributor over the > > matter of an email would be sad indeed. > > You don't know that yet. Many other contributors have not even used koji > yet. Others don't know that FC <= 4 is EOL. Others have done "make built" > without asking for a tag. You guess that they don't want the tag. But it > is likely they just don't know about the extra burden yet. Yes, I do know that. I said Ralf was the only person to "publicly refuse to do so". If others haven't spoken up, then they aren't publicly refusing to do so. Now, to address what you're really trying to point out, yes there certainly may be cases where maintainers simply don't know. That is one of the driving reasons I started this thread to being with. So far, it's actually working quite well. Several of the issues that were on the report have been fixed and as soon as rawhide materializes again I'll send out an updated one. josh From bugs.michael at gmx.net Tue May 15 15:57:10 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 17:57:10 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> Message-ID: <20070515175710.dec149e6.bugs.michael@gmx.net> On Tue, 15 May 2007 09:20:55 -0500 (CDT), Jima wrote: > 5. The development freezes have been done before, they just were enforced > quite poorly in Extras. To do some myth busting, Fedora Extras over the past years has been frozen only once. And that freeze was experimental and blocked all updates from entering the repo. Calling it "quite poorly" is unfair and unjustified. Just as with dist-fc7 we were still able to push individual packages and package sets into the repo. From bugs.michael at gmx.net Tue May 15 16:06:37 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 18:06:37 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179244566.3084.86.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <20070515174813.05d3929d.bugs.michael@gmx.net> <1179244566.3084.86.camel@zod.rchland.ibm.com> Message-ID: <20070515180637.f538b8af.bugs.michael@gmx.net> On Tue, 15 May 2007 10:56:06 -0500, Josh Boyer wrote: > I said Ralf was the only person to "publicly > refuse to do so". If others haven't spoken up, then they aren't > publicly refusing to do so. I prefer people, who voice their opinion, over silent people who sometimes drop off silently because they are fed up. From jwboyer at jdub.homelinux.org Tue May 15 16:09:33 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 11:09:33 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515180637.f538b8af.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <20070515174813.05d3929d.bugs.michael@gmx.net> <1179244566.3084.86.camel@zod.rchland.ibm.com> <20070515180637.f538b8af.bugs.michael@gmx.net> Message-ID: <1179245373.3084.90.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 18:06 +0200, Michael Schwendt wrote: > On Tue, 15 May 2007 10:56:06 -0500, Josh Boyer wrote: > > > I said Ralf was the only person to "publicly > > refuse to do so". If others haven't spoken up, then they aren't > > publicly refusing to do so. > > I prefer people, who voice their opinion, over silent people who > sometimes drop off silently because they are fed up. As do I. Very much so. That doesn't make my statement untruthful though :) josh From wwoods at redhat.com Tue May 15 16:11:05 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 15 May 2007 12:11:05 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515150020.GE2815@free.fr> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> Message-ID: <1179245466.1459.21.camel@metroid.rdu.redhat.com> On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > On Tue, May 15, 2007 at 10:16:27AM -0400, Jesse Keating wrote: > > > > See above. They go out as an update to Fedora 7 and thus get a nice > > announcement and such. > > Will there be a way to short-circuit the announcement and just update, > like it was possible before? Holy Zod, no. No no no. Very no. There will be no more silent updating of packages without explanation or at least a *chance* for testing. Yeah, I know this makes putting out updates slightly harder, but in my opinion the fact that we ever allowed this at all was a massive oversight, not a design feature. We will have to work slightly harder in order to Do The Right Thing for our users, to ensure package sanity and overall distribution stability. Those are our goals, and I hope you'll agree that they're worth working for. -w -------------- 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 opensource at till.name Tue May 15 16:23:33 2007 From: opensource at till.name (Till Maas) Date: Tue, 15 May 2007 18:23:33 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151114.35814.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <200705151114.35814.jkeating@redhat.com> Message-ID: <200705151823.34570.opensource@till.name> On Di Mai 15 2007, Jesse Keating wrote: > On Tuesday 15 May 2007 11:00:20 Patrice Dumas wrote: >> Will there be a way to short-circuit the announcement and just update, >> like it was possible before? > > No, as that is a very poor end user experience. Here I've got 40 updates, Will it possible to tell yum to only perform security updates then? E.g. do "yum --type security update" or something similiar? Regards, Till From fedora at leemhuis.info Tue May 15 16:28:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 May 2007 18:28:24 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515180637.f538b8af.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <20070515174813.05d3929d.bugs.michael@gmx.net> <1179244566.3084.86.camel@zod.rchland.ibm.com> <20070515180637.f538b8af.bugs.michael@gmx.net> Message-ID: <4649DFA8.8050100@leemhuis.info> On 15.05.2007 18:06, Michael Schwendt wrote: > On Tue, 15 May 2007 10:56:06 -0500, Josh Boyer wrote: > >> I said Ralf was the only person to "publicly >> refuse to do so". If others haven't spoken up, then they aren't >> publicly refusing to do so. > I prefer people, who voice their opinion, over silent people who > sometimes drop off silently because they are fed up. +1 The merge created quite some confusion. ACLs for CVS was one of the major things that created lots of confusion already and maybe came to fast without thinking it to the end completely before realizing it. There were many other, often smaller details that created confusion in the past weeks. Now due to a bad coincidence there is the switch to koji and the freeze at the same time -- that creates even more confusion and trouble then before (especially for those that don't follow fedora-maintainers closely). It's frustrating and I don't like that -- I really hope we do our work better in the future after F7 is out and the merge finished. But well, I assume most of us wanted the merge now for F7 afaics (and some people that are now yelled at work/worked hard to realize it -- let's not forget this). F7 as target and some delays here and there are probably the reason for the hectic and trouble we are now it. Not nice, but happens. So I'd say let's all be a bit patient -- let's get F7 out the door with koji and the freeze now and then things hopefully should sort out. If there are regressions then let's put them at the top of the todo list. The hopefully everyone is happy again in a months from now. CU thl From rc040203 at freenet.de Tue May 15 16:31:00 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 18:31:00 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179245466.1459.21.camel@metroid.rdu.redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> Message-ID: <1179246660.4735.548.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 12:11 -0400, Will Woods wrote: > On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > > On Tue, May 15, 2007 at 10:16:27AM -0400, Jesse Keating wrote: > > > > > > See above. They go out as an update to Fedora 7 and thus get a nice > > > announcement and such. > > > > Will there be a way to short-circuit the announcement and just update, > > like it was possible before? > > Holy Zod, no. No no no. Very no. > > There will be no more silent updating of packages without explanation > or at least a *chance* for testing. What you call testing, I call locking out updates and bug-fixes == regression > Yeah, I know this makes putting out updates slightly harder, == regression > but in my > opinion the fact that we ever allowed this at all was a massive > oversight, not a design feature. I disagree. Release early, release often is a feature, now you are spoiling one of the fundamental working principles of Fedora. > We will have to work slightly harder in order to Do The Right Thing for > our users, to ensure package sanity and overall distribution stability. We will see and I'll be delighted to be proven wrong, but I have seen too many project failing because some "test/release engineers" throught they could outweigh the "testing capability of the masses". > Those are our goals, and I hope you'll agree that they're worth working > for. Who is your? I presume it's RH Ralf From katzj at redhat.com Tue May 15 16:58:07 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 15 May 2007 12:58:07 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151823.34570.opensource@till.name> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <200705151114.35814.jkeating@redhat.com> <200705151823.34570.opensource@till.name> Message-ID: <1179248287.29594.5.camel@erebor.boston.redhat.com> On Tue, 2007-05-15 at 18:23 +0200, Till Maas wrote: > On Di Mai 15 2007, Jesse Keating wrote: > > On Tuesday 15 May 2007 11:00:20 Patrice Dumas wrote: > >> Will there be a way to short-circuit the announcement and just update, > >> like it was possible before? > > > > No, as that is a very poor end user experience. Here I've got 40 updates, > > Will it possible to tell yum to only perform security updates then? E.g. > do "yum --type security update" or something similiar? Yep; install the yum-security plugin and then do yum --security update Also, you can install updates based on CVE, bug number or advisory id. Jeremy From jkeating at redhat.com Tue May 15 16:58:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 12:58:18 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151823.34570.opensource@till.name> References: <200705141710.20460.jkeating@redhat.com> <200705151114.35814.jkeating@redhat.com> <200705151823.34570.opensource@till.name> Message-ID: <200705151258.19145.jkeating@redhat.com> On Tuesday 15 May 2007 12:23:33 Till Maas wrote: > Will it possible to tell yum to only perform security updates then? E.g. > do "yum --type security update" or something similiar? That is a possibility. The metadata about the update actually lives in the yum repodata so things like that are definitely possible. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue May 15 16:59:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 12:59:51 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179246660.4735.548.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> Message-ID: <200705151259.51792.jkeating@redhat.com> On Tuesday 15 May 2007 12:31:00 Ralf Corsepius wrote: > I disagree. Release early, release often is a feature, now you are > spoiling one of the fundamental working principles of Fedora. > > > We will have to work slightly harder in order to Do The Right Thing for > > our users, to ensure package sanity and overall distribution stability. > > We will see and I'll be delighted to be proven wrong, but I have seen > too many project failing because some "test/release engineers" throught > they could outweigh the "testing capability of the masses". Yeah, our users just want to continue seeing Fedora as one big beta for RHEL right? Who cares if we toss half-ass packages over the wall and it breaks for large majorities of our userbase. We'll just fix it soon enough and they'll deal right? Who cares about the stability of our distribution. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue May 15 16:57:14 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 18:57:14 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151114.35814.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <200705151114.35814.jkeating@redhat.com> Message-ID: <20070515165714.GG2815@free.fr> On Tue, May 15, 2007 at 11:14:35AM -0400, Jesse Keating wrote: > On Tuesday 15 May 2007 11:00:20 Patrice Dumas wrote: > > Will there be a way to short-circuit the announcement and just update, > > like it was possible before? > > No, as that is a very poor end user experience. Here I've got 40 updates, > without a clue as to why these updates exist and why I should use bandwidth > to pull them down. Updates without announcements / reasons is just chucking > grenades over the wall. In my opinion it really depends on the package and on the update. Sometimes you want to do annoucements, some time it is just a loss of time for the packager to do it and for the end-user to read it. So I think it would be much more efficient if it was possible to skip it. Of course it should also be easy to do a nice announcement. -- Pat From katzj at redhat.com Tue May 15 17:09:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 15 May 2007 13:09:32 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515165714.GG2815@free.fr> References: <200705141710.20460.jkeating@redhat.com> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <200705151114.35814.jkeating@redhat.com> <20070515165714.GG2815@free.fr> Message-ID: <1179248973.29594.9.camel@erebor.boston.redhat.com> On Tue, 2007-05-15 at 18:57 +0200, Patrice Dumas wrote: > On Tue, May 15, 2007 at 11:14:35AM -0400, Jesse Keating wrote: > > On Tuesday 15 May 2007 11:00:20 Patrice Dumas wrote: > > > Will there be a way to short-circuit the announcement and just update, > > > like it was possible before? > > > > No, as that is a very poor end user experience. Here I've got 40 updates, > > without a clue as to why these updates exist and why I should use bandwidth > > to pull them down. Updates without announcements / reasons is just chucking > > grenades over the wall. > > In my opinion it really depends on the package and on the update. Sometimes > you want to do annoucements, some time it is just a loss of time for the > packager to do it and for the end-user to read it. So I think it would > be much more efficient if it was possible to skip it. Of course it should > also be easy to do a nice announcement. >From the point of view of the person maintaining the user visible update tool, users *really do want to know* this information. And I get bugs filed about the fact that Extras packages don't currently have this information available. Jeremy From pertusus at free.fr Tue May 15 17:02:27 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 19:02:27 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179245466.1459.21.camel@metroid.rdu.redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> Message-ID: <20070515170227.GH2815@free.fr> On Tue, May 15, 2007 at 12:11:05PM -0400, Will Woods wrote: > On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > > On Tue, May 15, 2007 at 10:16:27AM -0400, Jesse Keating wrote: > > > > > > See above. They go out as an update to Fedora 7 and thus get a nice > > > announcement and such. > > > > Will there be a way to short-circuit the announcement and just update, > > like it was possible before? > > Holy Zod, no. No no no. Very no. > > There will be no more silent updating of packages without explanation > or at least a *chance* for testing. The issue of testing and of announcement are very different issues. > Yeah, I know this makes putting out updates slightly harder, but in my > opinion the fact that we ever allowed this at all was a massive > oversight, not a design feature. I disagree. In my opinion the right way is to have the infrastructure that allows to do announcements, while keeping the possibility not to use it. > We will have to work slightly harder in order to Do The Right Thing for > our users, to ensure package sanity and overall distribution stability. > Those are our goals, and I hope you'll agree that they're worth working > for. Indeed, but it isn't the point. Sometimes doing the right thing is not losing time when there are better things to work on. -- Pat From bugs.michael at gmx.net Tue May 15 17:15:07 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 19:15:07 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151259.51792.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> Message-ID: <20070515191507.cfeb4274.bugs.michael@gmx.net> On Tue, 15 May 2007 12:59:51 -0400, Jesse Keating wrote: > On Tuesday 15 May 2007 12:31:00 Ralf Corsepius wrote: > > I disagree. Release early, release often is a feature, now you are > > spoiling one of the fundamental working principles of Fedora. > > > > > We will have to work slightly harder in order to Do The Right Thing for > > > our users, to ensure package sanity and overall distribution stability. > > > > We will see and I'll be delighted to be proven wrong, but I have seen > > too many project failing because some "test/release engineers" throught > > they could outweigh the "testing capability of the masses". > > Yeah, our users just want to continue seeing Fedora as one big beta for RHEL > right? Who cares if we toss half-ass packages over the wall and it breaks > for large majorities of our userbase. We'll just fix it soon enough and > they'll deal right? Who cares about the stability of our distribution. > Eh? What has this comment to do here? Or have you realised that too many users are burnt by the frequent updates and upgrades that are pushed out to Fedora Core 5 and Fedora Core 6? That is the #1 complaint by users who have wandered off to Ubuntu, for example. Released Updates which break something badly. Wrapped into nice words in good-looking update announcements, which advertise everything but the regression and breakage. How does that help us? The testing is missing, not the announcements. Anyway, I wonder what this has to do with a sudden and late freeze of Extras' packages? From pertusus at free.fr Tue May 15 17:11:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 19:11:34 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705151113.07471.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179236633.3084.51.camel@zod.rchland.ibm.com> <20070515145859.GD2815@free.fr> <200705151113.07471.jkeating@redhat.com> Message-ID: <20070515171134.GI2815@free.fr> On Tue, May 15, 2007 at 11:13:07AM -0400, Jesse Keating wrote: > > To be perfectly honest, I'm not completely happy with this process for the > final freeze either. This was an experiment for the Fedora 7 release, and it > went really well for the test release freezes. I agree that the final freeze > should be done differently, however I didn't want to change it at this point. Agreed. I think it should be changed for the next release, it is to late to change it now. But I wanted to voice out my concern so that things are changed next time. I already complained at the first time the release process was outlined but nobody cared. (As a side note, for the freeze there was still plague used and we hadn't to ask to push so of course it was better than for the release.) > Asking how many were rejected isn't quite fair. It's not the people who are > asking for tagging that I'm concerned with, it's the people who just don't > realize we're in a freeze and happily drop in a soname bump that breaks a ton That shouldn't happen if instead of make build, one have to do make release-build when we are in freeze. > of packages or other such acts without noticing that we're in a freeze and > doing such can cause problems with the release. This has happened in the > past, I'm not just being overly paranoid. I very much want there to be less > overhead, and I welcome any effort into the workflow that gets us there, but > at the same time we have to be able to manage a freeze and have control over > what gets in and what doesn't. That's why I think that rel-eng people could disallow a push and should have the last word, at least until the packager had time to say why he wants it. That's what was done for extras and it worked well -- although I agree that how it was done in extras is not necessarily suitable for merged fedora, especially because of the constraints linked with composing the release. -- Pat From jkeating at redhat.com Tue May 15 17:22:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 13:22:00 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515191507.cfeb4274.bugs.michael@gmx.net> References: <200705141710.20460.jkeating@redhat.com> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> Message-ID: <200705151322.01037.jkeating@redhat.com> On Tuesday 15 May 2007 13:15:07 Michael Schwendt wrote: > Eh? What has this comment to do here? Or have you realised that too many > users are burnt by the frequent updates and upgrades that are pushed out > to Fedora Core 5 and Fedora Core 6? That is the #1 complaint by users who > have wandered off to Ubuntu, for example. Released Updates which break > something badly. Wrapped into nice words in good-looking update > announcements, which advertise everything but the regression and > breakage. How does that help us? The testing is missing, not the > announcements. Correct the testing, forcing things to go into an updates-testing queue before going out to the rest of the world. Announcement about what has changed and what should be tested, the ability to pull something from -testing before it hits the wide world. Ralf's statement is that we shouldn't bother, and we should just use our end users for our testing purposes. > Anyway, I wonder what this has to do with a sudden and late freeze of > Extras' packages? It doesn't, it has to do with where the topic has drifted, the use of an update tool to issue updates to released Fedoras. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Tue May 15 17:25:33 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 15 May 2007 13:25:33 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179246660.4735.548.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> Message-ID: <1179249933.1459.35.camel@metroid.rdu.redhat.com> On Tue, 2007-05-15 at 18:31 +0200, Ralf Corsepius wrote: > On Tue, 2007-05-15 at 12:11 -0400, Will Woods wrote: > > On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > > > Will there be a way to short-circuit the announcement and just update, > > > like it was possible before? > > > > Holy Zod, no. No no no. Very no. > > > > There will be no more silent updating of packages without explanation > > or at least a *chance* for testing. > What you call testing, I call locking out updates and bug-fixes > == regression Excuse me? Who said anything about locking out updates or bug fixes? I'm just asking that packages spend a few days in a -testing repository - which is open to the entire world - to be sanity tested by QA and interested users before going to the updates repo. How does that lock out *anything*? What are you even talking about? Where are you drawing these ridiculous conclusions from? > > Yeah, I know this makes putting out updates slightly harder, > > == regression You keep using that word. I do not think it means what you think it does. Let me get this straight: You think that being able to cram changes down the throats of ~2mil users without justification or testing is a *feature*, and that requiring (world-accessible) testing is a *bug*. > > but in my > > opinion the fact that we ever allowed this at all was a massive > > oversight, not a design feature. > > I disagree. Release early, release often is a feature, now you are > spoiling one of the fundamental working principles of Fedora. How is it spoiling anything? The packages are still available immediately after build, just like before. I think you have misunderstood what we're talking about here. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Tue May 15 17:26:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 15 May 2007 19:26:13 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515191507.cfeb4274.bugs.michael@gmx.net> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> Message-ID: <4649ED35.9030607@leemhuis.info> On 15.05.2007 19:15, Michael Schwendt wrote: > On Tue, 15 May 2007 12:59:51 -0400, Jesse Keating wrote: >> On Tuesday 15 May 2007 12:31:00 Ralf Corsepius wrote: >>> I disagree. Release early, release often is a feature, now you are >>> spoiling one of the fundamental working principles of Fedora. >>>> We will have to work slightly harder in order to Do The Right Thing for >>>> our users, to ensure package sanity and overall distribution stability. >>> We will see and I'll be delighted to be proven wrong, but I have seen >>> too many project failing because some "test/release engineers" throught >>> they could outweigh the "testing capability of the masses". >> Yeah, our users just want to continue seeing Fedora as one big beta for RHEL >> right? Who cares if we toss half-ass packages over the wall and it breaks >> for large majorities of our userbase. We'll just fix it soon enough and >> they'll deal right? Who cares about the stability of our distribution. >> > Eh? What has this comment to do here? Or have you realised that too many > users are burnt by the frequent updates and upgrades that are pushed out > to Fedora Core 5 and Fedora Core 6? That is the #1 complaint by users who > have wandered off to Ubuntu, for example. Released Updates which break > something badly. [...] I agree that we to often released packages that broke stuff. I hope that gets better with bodhi (and the QA around it) in the merged world. But I'm confident that lots of users like Fedora (or might even have switched from Ubuntu to Fedora) because we serve updates for released distribution that bring new features or better hardware support. Especially the latter is something where Fedora with its frequent kernels updates as well as updates for Sane or X give users with brand new hardware a chance to run it with Linux -- the other bigs distros fail to serve something similar afaics. Cu thl From jkeating at redhat.com Tue May 15 17:33:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 13:33:58 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649ED35.9030607@leemhuis.info> References: <200705141710.20460.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> Message-ID: <200705151333.59017.jkeating@redhat.com> On Tuesday 15 May 2007 13:26:13 Thorsten Leemhuis wrote: > But I'm confident that lots of users like Fedora (or might even have > switched from Ubuntu to Fedora) because we serve updates for released > distribution that bring new features or better hardware support. > > Especially the latter is something where Fedora with its frequent > kernels updates as well as updates for Sane or X give users with brand > new hardware a chance to run it with Linux -- the other bigs distros > fail to serve something similar afaics. Whats neat is that the packages you mentioned already use a bodhi like tool to generate the updates. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Tue May 15 17:35:04 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 15 May 2007 13:35:04 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515170227.GH2815@free.fr> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <20070515170227.GH2815@free.fr> Message-ID: <1179250504.1459.46.camel@metroid.rdu.redhat.com> On Tue, 2007-05-15 at 19:02 +0200, Patrice Dumas wrote: > On Tue, May 15, 2007 at 12:11:05PM -0400, Will Woods wrote: > > On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > > > We will have to work slightly harder in order to Do The Right Thing for > > our users, to ensure package sanity and overall distribution stability. > > Those are our goals, and I hope you'll agree that they're worth working > > for. > > Indeed, but it isn't the point. Sometimes doing the right thing is not > losing time when there are better things to work on. So, what I hear you saying is that - regardless of whether users want it or not - it's not worth *your* time to fill in the blanks on a short message saying: package-1.2.3-4.fc7 is a (bugfix,enhancement,security) update which (adds the following features, fixes the following bugs): ... We could even auto-fill the message from the changelog entries. Or.. maybe you also have better things to work on than adding changelog entries to your RPMS? How about comments? Maybe I think I have better things to do than to comment my code. Documentation, too. Look, here's the bottom line: people want to know what's changed when you update packages on their systems. We can work together to make it easy for you to provide this information. Let's work together to make the infrastructure better rather than just refusing to use it. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Tue May 15 17:53:51 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 15 May 2007 19:53:51 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151259.51792.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> Message-ID: <4649F3AF.2090306@hhs.nl> Replying a bit out of context (for those using a threaded reader), as I already deleted the mother post I should have replied too. First of all let me say that I'm fine with new packages and package updates going through updates now, and with updates needing a good reason to be released, and with all updates (including new packages) needing an announcement. However I thought that we had agreed that _new_ packages don't need to go through updates-testing, as they (normally) don't cause any regressions. Also I would like to see simple updates not going through updates-testing too. most of the bug reports I get are either: a) packaging/cosmetic -> defer to next release b) crashers / segfaults The b) bugs are often fixed with a single line patch, with little chance of causing regressions, in this scenario I would like to be able to have the fix in the hand of (non testing) end users within a day, as I could do until now. If the fix is more invasive, then using updates-testing is fine ofcourse, but for important, simple (obviously correct) fixes, I would like to be able to skip updates-testing. For the rel-eng people, take the 64 bit pygame update as an example (although the needing 2 itterations part makes that a bad example) Regards, Hans From sundaram at fedoraproject.org Tue May 15 17:42:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 23:12:59 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <464966A3.9090101@leemhuis.info> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> Message-ID: <4649F123.8070701@fedoraproject.org> Thorsten Leemhuis wrote: > The F7 isos of course still has foo-1.1-4.fc7.i386.rpm; so if someone > has a full up2date F6-system two weeks after F7 got released and then > does the upgrade from F6 to F7 with the media he won't get foo updated > anyway. He'll get it with the first "yum update" after the dist upgrade. > > So we need to *always* make sure the upgrade path is proper, not only at > release time. I think you missed out a part of what I said which was confined to the release. The updates system should check for this and refuse to publish if a sane update path doesn't exist from a previous release. As such I think Rahul is shooting way over the top with > pulling them from the repo, as that creates even more trouble for users. Package is broken. Maintainer refuses to fix it. Others are not interested. Pulling the packages is the right way to go since they are implicitly orphaned packages. What alternative are you suggesting? Rahul From sundaram at fedoraproject.org Tue May 15 17:46:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 23:16:58 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649F3AF.2090306@hhs.nl> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> Message-ID: <4649F212.1030302@fedoraproject.org> Hans de Goede wrote: > If the fix is more invasive, then using updates-testing is fine > ofcourse, but for important, simple (obviously correct) fixes, I would > like to be able to skip updates-testing. Even "obviously correct" fixes have caused major regressions. Your packages would reach updates after sitting in updates-testing for a small amount of time. What's wrong with it? The only exception I can see is critical security fixes where the update has *only the fix*. Rahul From j.w.r.degoede at hhs.nl Tue May 15 18:05:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 15 May 2007 20:05:06 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649F212.1030302@fedoraproject.org> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> Message-ID: <4649F652.9000203@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: > >> If the fix is more invasive, then using updates-testing is fine >> ofcourse, but for important, simple (obviously correct) fixes, I would >> like to be able to skip updates-testing. > > Even "obviously correct" fixes have caused major regressions. Your > packages would reach updates after sitting in updates-testing for a > small amount of time. What's wrong with it? > That small amount of time. There should be a balance between the chance for regressions and the time spend in updates-testing. If the chance for regressions is close to 0, the time spend in updates-testing should be 0. Regards, Hans From jwboyer at jdub.homelinux.org Tue May 15 17:49:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 12:49:34 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <4649F123.8070701@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> Message-ID: <1179251374.3084.115.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 23:12 +0530, Rahul Sundaram wrote: > As such I think Rahul is shooting way over the top with > > pulling them from the repo, as that creates even more trouble for users. > > Package is broken. Maintainer refuses to fix it. Others are not > interested. Pulling the packages is the right way to go since they are > implicitly orphaned packages. What alternative are you suggesting? That's not quite true in this case. The package isn't broken. The tag on which it sits is. Just clarifying that. josh From mtasaka at ioa.s.u-tokyo.ac.jp Tue May 15 17:51:39 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 16 May 2007 02:51:39 +0900 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151333.59017.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <200705151333.59017.jkeating@redhat.com> Message-ID: <4649F32B.5040002@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote, at 05/16/2007 02:33 AM +9:00: > On Tuesday 15 May 2007 13:26:13 Thorsten Leemhuis wrote: >> But I'm confident that lots of users like Fedora (or might even have >> switched from Ubuntu to Fedora) because we serve updates for released >> distribution that bring new features or better hardware support. >> >> Especially the latter is something where Fedora with its frequent >> kernels updates as well as updates for Sane or X give users with brand >> new hardware a chance to run it with Linux -- the other bigs distros >> fail to serve something similar afaics. > > Whats neat is that the packages you mentioned already use a bodhi like tool to > generate the updates. IMO this discussion never ends until someone writes precisely about bodhi(?) and how to release updates rpms using bodhi (again ?) Actually I cannot tell at this point to what degree requests for update gets complicated..... Mamoru From jwboyer at jdub.homelinux.org Tue May 15 17:51:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 12:51:39 -0500 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649F652.9000203@hhs.nl> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> <4649F652.9000203@hhs.nl> Message-ID: <1179251499.3084.118.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 20:05 +0200, Hans de Goede wrote: > Rahul Sundaram wrote: > > Hans de Goede wrote: > > > >> If the fix is more invasive, then using updates-testing is fine > >> ofcourse, but for important, simple (obviously correct) fixes, I would > >> like to be able to skip updates-testing. > > > > Even "obviously correct" fixes have caused major regressions. Your > > packages would reach updates after sitting in updates-testing for a > > small amount of time. What's wrong with it? > > > > That small amount of time. There should be a balance between the chance for > regressions and the time spend in updates-testing. If the chance for > regressions is close to 0, the time spend in updates-testing should be 0. Since the tool isn't available yet I can't be sure, but I believe it's a manual push to -updates by the maintainer anyway. Theoretically and from a technical perspective, you could push it immediately. josh From sundaram at fedoraproject.org Tue May 15 17:55:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 23:25:53 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179251374.3084.115.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> Message-ID: <4649F429.2060006@fedoraproject.org> Josh Boyer wrote: > On Tue, 2007-05-15 at 23:12 +0530, Rahul Sundaram wrote: >> As such I think Rahul is shooting way over the top with >>> pulling them from the repo, as that creates even more trouble for users. >> Package is broken. Maintainer refuses to fix it. Others are not >> interested. Pulling the packages is the right way to go since they are >> implicitly orphaned packages. What alternative are you suggesting? > > That's not quite true in this case. The package isn't broken. The tag > on which it sits is. Just clarifying that. Purely from the end user perspective what difference does it make? I don't think the implementation details change the gist of my argument. Maintainer politics shouldn't affect end users in a opaque way. Rahul From sundaram at fedoraproject.org Tue May 15 17:59:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 23:29:24 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649F652.9000203@hhs.nl> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> <4649F652.9000203@hhs.nl> Message-ID: <4649F4FC.80405@fedoraproject.org> Hans de Goede wrote: > Rahul Sundaram wrote: >> Hans de Goede wrote: >> >>> If the fix is more invasive, then using updates-testing is fine >>> ofcourse, but for important, simple (obviously correct) fixes, I >>> would like to be able to skip updates-testing. >> >> Even "obviously correct" fixes have caused major regressions. Your >> packages would reach updates after sitting in updates-testing for a >> small amount of time. What's wrong with it? >> > > That small amount of time. There should be a balance between the chance > for regressions and the time spend in updates-testing. If the chance for > regressions is close to 0, the time spend in updates-testing should be 0. The chance for regressions is pretty much never zero. End users would very much be willing to wait a small amount of time if gives testers a better chance to check for issues and improve the quality of updates. What is the big rush anyway? Have you read any of the recent discussions in fedora-list or forums lately? Rahul From jwboyer at jdub.homelinux.org Tue May 15 18:08:34 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 13:08:34 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <4649F429.2060006@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> Message-ID: <1179252514.3084.121.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 23:25 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Tue, 2007-05-15 at 23:12 +0530, Rahul Sundaram wrote: > >> As such I think Rahul is shooting way over the top with > >>> pulling them from the repo, as that creates even more trouble for users. > >> Package is broken. Maintainer refuses to fix it. Others are not > >> interested. Pulling the packages is the right way to go since they are > >> implicitly orphaned packages. What alternative are you suggesting? > > > > That's not quite true in this case. The package isn't broken. The tag > > on which it sits is. Just clarifying that. > > Purely from the end user perspective what difference does it make? I None. But then again, neither does your suggestion of pulling the packages out of the repo :). > don't think the implementation details change the gist of my argument. > Maintainer politics shouldn't affect end users in a opaque way. In this particular thread, it's all about maintainer politics at the moment. "Broken package" is not entirely true and rather than have another 80 fucking emails about why it is or is not true is something I'd rather avoid. josh From sundaram at fedoraproject.org Tue May 15 18:21:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 23:51:00 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179252514.3084.121.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> Message-ID: <4649FA0C.6090502@fedoraproject.org> Josh Boyer wrote: > On Tue, 2007-05-15 at 23:25 +0530, Rahul Sundaram wrote: >> Josh Boyer wrote: >>> On Tue, 2007-05-15 at 23:12 +0530, Rahul Sundaram wrote: >>>> As such I think Rahul is shooting way over the top with >>>>> pulling them from the repo, as that creates even more trouble for users. >>>> Package is broken. Maintainer refuses to fix it. Others are not >>>> interested. Pulling the packages is the right way to go since they are >>>> implicitly orphaned packages. What alternative are you suggesting? >>> That's not quite true in this case. The package isn't broken. The tag >>> on which it sits is. Just clarifying that. >> Purely from the end user perspective what difference does it make? I > > None. But then again, neither does your suggestion of pulling the > packages out of the repo :). It does make a pretty big difference in the overall quality of the repository. I can solidly claim that every single package in the release has a good update path. Quality and robustness of the repository and updates is one of the biggest problems we need to tackle. I see people suggesting that pulling off packages is over the top but I dont see anyone suggesting any other alternative. Does anyone want to knowingly put packages into the release with fundamental issues like this? There is a usability issue in that packages being dropped are not immediately visible to end users. There are other potential solutions or that. I have already suggested before to have a live upgrade tool/Anaconda module which checks for packages that does not have a proper update path (Packages that orphaned/pulled off the repository for any other reasons such as licensing, improperly configured third party repository packages ,custom packages etc) and list them with any possible solutions. Rahul From j.w.r.degoede at hhs.nl Tue May 15 18:35:27 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 15 May 2007 20:35:27 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649F4FC.80405@fedoraproject.org> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> <4649F652.9000203@hhs.nl> <4649F4FC.80405@fedoraproject.org> Message-ID: <4649FD6F.8030101@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: >> Rahul Sundaram wrote: >>> Hans de Goede wrote: >>> >>>> If the fix is more invasive, then using updates-testing is fine >>>> ofcourse, but for important, simple (obviously correct) fixes, I >>>> would like to be able to skip updates-testing. >>> >>> Even "obviously correct" fixes have caused major regressions. Your >>> packages would reach updates after sitting in updates-testing for a >>> small amount of time. What's wrong with it? >>> >> >> That small amount of time. There should be a balance between the >> chance for regressions and the time spend in updates-testing. If the >> chance for regressions is close to 0, the time spend in >> updates-testing should be 0. > > The chance for regressions is pretty much never zero. No, but often close to it (assuming our buildsys does reproducable builds, which AFAIK it does). I regularry get crashers reported where upon debugging, the cause is obvious and so is the fix -> close to 0 chance of regression. > End users would > very much be willing to wait a small amount of time if gives testers a > better chance to check for issues and improve the quality of updates. > What is the big rush anyway? For non obscure crasher / application not starting bugs I would rather get the fix out asap then wait a few days and watch dozens of duplicate bugs pop up. Regards, Hans From sundaram at fedoraproject.org Tue May 15 18:27:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 May 2007 23:57:34 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649FD6F.8030101@hhs.nl> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> <4649F652.9000203@hhs.nl> <4649F4FC.80405@fedoraproject.org> <4649FD6F.8030101@hhs.nl> Message-ID: <4649FB96.2000904@fedoraproject.org> Hans de Goede wrote: > > For non obscure crasher / application not starting bugs I would rather > get the fix out asap then wait a few days and watch dozens of duplicate > bugs pop up. This is a valid point. Critical security fixes and bugs should have a exception when the only change being made in the update is the fix. All other packages go through updates-testing. Is that acceptable? Rahul From wwoods at redhat.com Tue May 15 18:29:54 2007 From: wwoods at redhat.com (Will Woods) Date: Tue, 15 May 2007 14:29:54 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649FB96.2000904@fedoraproject.org> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> <4649F652.9000203@hhs.nl> <4649F4FC.80405@fedoraproject.org> <4649FD6F.8030101@hhs.nl> <4649FB96.2000904@fedoraproject.org> Message-ID: <1179253794.1459.48.camel@metroid.rdu.redhat.com> On Tue, 2007-05-15 at 23:57 +0530, Rahul Sundaram wrote: > Hans de Goede wrote: > > > > For non obscure crasher / application not starting bugs I would rather > > get the fix out asap then wait a few days and watch dozens of duplicate > > bugs pop up. > > This is a valid point. Critical security fixes and bugs should have a > exception when the only change being made in the update is the fix. All > other packages go through updates-testing. Is that acceptable? Yes, security fixes can skip updates-testing. But they definitely need an announcement (so that appropriate metadata is generated and yum --security can pick up the fix). -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Tue May 15 18:47:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 15 May 2007 20:47:24 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649FB96.2000904@fedoraproject.org> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> <4649F652.9000203@hhs.nl> <4649F4FC.80405@fedoraproject.org> <4649FD6F.8030101@hhs.nl> <4649FB96.2000904@fedoraproject.org> Message-ID: <464A003C.4000307@hhs.nl> Rahul Sundaram wrote: > Hans de Goede wrote: >> >> For non obscure crasher / application not starting bugs I would rather >> get the fix out asap then wait a few days and watch dozens of >> duplicate bugs pop up. > > This is a valid point. Critical security fixes and bugs should have a > exception when the only change being made in the update is the fix. All > other packages go through updates-testing. Is that acceptable? > That is exactly what I was asking for, now the only remaining problem is the definition of what is a critical bug fix. I think it would be best to only allow updates-testing skipping by sending a request to rel-eng and getting permission, much like this is done now for "breaking" the freeze. Regards, Hans From jwboyer at jdub.homelinux.org Tue May 15 18:32:28 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 13:32:28 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <4649FA0C.6090502@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> Message-ID: <1179253948.3084.133.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 23:51 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > On Tue, 2007-05-15 at 23:25 +0530, Rahul Sundaram wrote: > >> Josh Boyer wrote: > >>> On Tue, 2007-05-15 at 23:12 +0530, Rahul Sundaram wrote: > >>>> As such I think Rahul is shooting way over the top with > >>>>> pulling them from the repo, as that creates even more trouble for users. > >>>> Package is broken. Maintainer refuses to fix it. Others are not > >>>> interested. Pulling the packages is the right way to go since they are > >>>> implicitly orphaned packages. What alternative are you suggesting? > >>> That's not quite true in this case. The package isn't broken. The tag > >>> on which it sits is. Just clarifying that. > >> Purely from the end user perspective what difference does it make? I > > > > None. But then again, neither does your suggestion of pulling the > > packages out of the repo :). > > It does make a pretty big difference in the overall quality of the > repository. I can solidly claim that every single package in the release > has a good update path. Having the ability to make that claim is ridiculous if you accomplish it by yanking the damn packages out of the repository. Especially when it's over something as trivial as a tag. YOU ARE NOT HELPING END USERS BY DOING THAT. Look at the zope thread from last week if you don't believe me. And that is a case where the package _is_ broken and it's not just a matter of a tag. > Quality and robustness of the repository and > updates is one of the biggest problems we need to tackle. We are tackling it. > I see people > suggesting that pulling off packages is over the top but I dont see > anyone suggesting any other alternative. I suggested we wait a couple days. Ralf has not officially declared his packages to be orphaned. I'm hoping he'll be amenable to perhaps another maintainer submitting the tag request since he's taking a break from Fedora. > Does anyone want to knowingly > put packages into the release with fundamental issues like this? I don't think anyone likes to have broken upgrade paths, no. > There is a usability issue in that packages being dropped are not > immediately visible to end users. There are other potential solutions or > that. I have already suggested before to have a live upgrade > tool/Anaconda module which checks for packages that does not have a > proper update path (Packages that orphaned/pulled off the repository for > any other reasons such as licensing, improperly configured third party > repository packages ,custom packages etc) and list them with any > possible solutions. Yeah a tool like that would be nice. It is entirely too late for this particular situation, but it would be nice indeed. josh From bugs.michael at gmx.net Tue May 15 18:38:24 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 20:38:24 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <4649F123.8070701@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> Message-ID: <20070515203824.0cb0149c.bugs.michael@gmx.net> On Tue, 15 May 2007 23:12:59 +0530, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > > The F7 isos of course still has foo-1.1-4.fc7.i386.rpm; so if someone > > has a full up2date F6-system two weeks after F7 got released and then > > does the upgrade from F6 to F7 with the media he won't get foo updated > > anyway. He'll get it with the first "yum update" after the dist upgrade. > > > > So we need to *always* make sure the upgrade path is proper, not only at > > release time. > > I think you missed out a part of what I said which was confined to the > release. The updates system should check for this and refuse to publish > if a sane update path doesn't exist from a previous release. That updates for dist N would have to wait for updates for dist N+1 would be unfortunate. From bugs.michael at gmx.net Tue May 15 18:43:46 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 20:43:46 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649F32B.5040002@ioa.s.u-tokyo.ac.jp> References: <200705141710.20460.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <200705151333.59017.jkeating@redhat.com> <4649F32B.5040002@ioa.s.u-tokyo.ac.jp> Message-ID: <20070515204346.ee5a138e.bugs.michael@gmx.net> On Wed, 16 May 2007 02:51:39 +0900, Mamoru Tasaka wrote: > IMO this discussion never ends until someone writes precisely about > bodhi(?) and how to release updates rpms using bodhi (again ?) > Actually I cannot tell at this point to what degree requests for > update gets complicated..... bodhi is a web-based updates system. Play with a test preview instance here: http://publictest2.fedora.redhat.com It doesn't add any testing or testing results. So, if nobody in updates-testing gives feedback on your stuff, there is no gain. From sundaram at fedoraproject.org Tue May 15 18:44:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 00:14:06 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515203824.0cb0149c.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <20070515203824.0cb0149c.bugs.michael@gmx.net> Message-ID: <4649FF76.7050603@fedoraproject.org> Michael Schwendt wrote: > On Tue, 15 May 2007 23:12:59 +0530, Rahul Sundaram wrote: > >> Thorsten Leemhuis wrote: >> >>> The F7 isos of course still has foo-1.1-4.fc7.i386.rpm; so if someone >>> has a full up2date F6-system two weeks after F7 got released and then >>> does the upgrade from F6 to F7 with the media he won't get foo updated >>> anyway. He'll get it with the first "yum update" after the dist upgrade. >>> >>> So we need to *always* make sure the upgrade path is proper, not only at >>> release time. >> I think you missed out a part of what I said which was confined to the >> release. The updates system should check for this and refuse to publish >> if a sane update path doesn't exist from a previous release. > > That updates for dist N would have to wait for updates for dist N+1 would be > unfortunate. Maintainers don't necessarily have to wait. They just need to fix it simultaneously when they do an update. That is a bit more work but I don't think that's unfortunate. Rahul From sundaram at fedoraproject.org Tue May 15 18:44:57 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 00:14:57 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179253948.3084.133.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> Message-ID: <4649FFA9.1060904@fedoraproject.org> Josh Boyer wrote: > I suggested we wait a couple days. Ralf has not officially declared his > packages to be orphaned. I'm hoping he'll be amenable to perhaps > another maintainer submitting the tag request since he's taking a break > from Fedora. That's all well and good for this specific instance but I am talking more about a general policy. How are you going to handle instances where maintainers refuse to cooperate? Step in and workaround them or consider the packages orphaned and pull them off? Rahul From jwboyer at jdub.homelinux.org Tue May 15 18:49:06 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 13:49:06 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <4649FFA9.1060904@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> Message-ID: <1179254946.3084.137.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 00:14 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > > I suggested we wait a couple days. Ralf has not officially declared his > > packages to be orphaned. I'm hoping he'll be amenable to perhaps > > another maintainer submitting the tag request since he's taking a break > > from Fedora. > > That's all well and good for this specific instance but I am talking > more about a general policy. How are you going to handle instances where > maintainers refuse to cooperate? Step in and workaround them or consider > the packages orphaned and pull them off? I have no energy to discuss some theoretical policy for a situation that should hopefully not occur more than a few times. I'm not saying you're wrong to address that, however. If you would like to have a discussion on that, please start a new thread. It's not a discussion or policy that will be finalized before F7 releases. josh From sundaram at fedoraproject.org Tue May 15 18:53:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 00:23:34 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179254946.3084.137.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> <1179254946.3084.137.camel@zod.rchland.ibm.com> Message-ID: <464A01AE.70007@fedoraproject.org> Josh Boyer wrote: > On Wed, 2007-05-16 at 00:14 +0530, Rahul Sundaram wrote: >> Josh Boyer wrote: >> >>> I suggested we wait a couple days. Ralf has not officially declared his >>> packages to be orphaned. I'm hoping he'll be amenable to perhaps >>> another maintainer submitting the tag request since he's taking a break >>> from Fedora. >> That's all well and good for this specific instance but I am talking >> more about a general policy. How are you going to handle instances where >> maintainers refuse to cooperate? Step in and workaround them or consider >> the packages orphaned and pull them off? > > I have no energy to discuss some theoretical policy for a situation that > should hopefully not occur more than a few times. I'm not saying you're > wrong to address that, however. If you would like to have a discussion > on that, please start a new thread. It's not a discussion or policy > that will be finalized before F7 releases. I guess that depends on things like whether Ralf wants to follow the freeze process or not. Rahul From bugs.michael at gmx.net Tue May 15 18:57:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 15 May 2007 20:57:55 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <4649FF76.7050603@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <20070515203824.0cb0149c.bugs.michael@gmx.net> <4649FF76.7050603@fedoraproject.org> Message-ID: <20070515205755.38ec6de0.bugs.michael@gmx.net> On Wed, 16 May 2007 00:14:06 +0530, Rahul Sundaram wrote: > >>> So we need to *always* make sure the upgrade path is proper, not only at > >>> release time. > >> > >> I think you missed out a part of what I said which was confined to the > >> release. The updates system should check for this and refuse to publish > >> if a sane update path doesn't exist from a previous release. > > > > That updates for dist N would have to wait for updates for dist N+1 would be > > unfortunate. > > Maintainers don't necessarily have to wait. They just need to fix it > simultaneously when they do an update. That is a bit more work but I > don't think that's unfortunate. I think you have misunderstood the fundamental problem. For a second try, all context is in above quotes. From jwboyer at jdub.homelinux.org Tue May 15 19:08:49 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 14:08:49 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <464A01AE.70007@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> <1179254946.3084.137.camel@zod.rchland.ibm.com> <464A01AE.70007@fedoraproject.org> Message-ID: <1179256129.3084.145.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 00:23 +0530, Rahul Sundaram wrote: > >> That's all well and good for this specific instance but I am talking > >> more about a general policy. How are you going to handle instances where > >> maintainers refuse to cooperate? Step in and workaround them or consider > >> the packages orphaned and pull them off? > > > > I have no energy to discuss some theoretical policy for a situation that > > should hopefully not occur more than a few times. I'm not saying you're > > wrong to address that, however. If you would like to have a discussion > > on that, please start a new thread. It's not a discussion or policy > > that will be finalized before F7 releases. > > I guess that depends on things like whether Ralf wants to follow the > freeze process or not. No, it doesn't. Making a general policy to solve the current situation will not be accomplished through the proper channels before Thursday, which is when Deep Freeze occurs. Creating such a general policy _cannot_ be rushed. It needs to be drafted, posted to -maintainers, solicited for feedback, revised, and sent to FESCo. For this current situation, Ralf has already stated that he feels it is rel-eng's responsibility to fix the upgrade paths for his packages. At best, Ralf will submit a request himself. In the middle, he'll be agreeable to another maintainer doing it on his behalf. At worst, someone from rel-eng can do it with a bit of proper research. I am prepared to do that as it seems to be the only way to solve this at the moment. josh From sundaram at fedoraproject.org Tue May 15 19:13:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 00:43:43 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179256129.3084.145.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> <1179254946.3084.137.camel@zod.rchland.ibm.com> <464A01AE.70007@fedoraproject.org> <1179256129.3084.145.camel@zod.rchland.ibm.com> Message-ID: <464A0667.7030301@fedoraproject.org> Josh Boyer wrote: At worst, > someone from rel-eng can do it with a bit of proper research. I am > prepared to do that as it seems to be the only way to solve this at the > moment. So you are going to work around the maintainer if needed. That's what I wanted to know. Thanks. Rahul From jwboyer at jdub.homelinux.org Tue May 15 19:33:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 14:33:23 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <464A0667.7030301@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> <1179254946.3084.137.camel@zod.rchland.ibm.com> <464A01AE.70007@fedoraproject.org> <1179256129.3084.145.camel@zod.rchland.ibm.com> <464A0667.7030301@fedoraproject.org> Message-ID: <1179257603.3084.153.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 00:43 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > At worst, > > someone from rel-eng can do it with a bit of proper research. I am > > prepared to do that as it seems to be the only way to solve this at the > > moment. > > So you are going to work around the maintainer if needed. Only because Ralf explicitly said he feels it's rel-eng's responsibility to fix it. I don't agree with that statement at all, but had he not said that I wouldn't touch the packages. > That's what I > wanted to know. Thanks. You're still going to hold the general policy discussion though, correct? Since that is indeed something that needs to be done in the long run. Or was all your posturing about that simply to get me to fix the current situation? josh From sundaram at fedoraproject.org Tue May 15 19:38:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 01:08:36 +0530 Subject: Broken upgrade paths in F7 In-Reply-To: <1179257603.3084.153.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> <1179254946.3084.137.camel@zod.rchland.ibm.com> <464A01AE.70007@fedoraproject.org> <1179256129.3084.145.camel@zod.rchland.ibm.com> <464A0667.7030301@fedoraproject.org> <1179257603.3084.153.camel@zod.rchland.ibm.com> Message-ID: <464A0C3C.2080308@fedoraproject.org> Josh Boyer wrote: > > You're still going to hold the general policy discussion though, > correct? Since that is indeed something that needs to be done in the > long run. Yes Or was all your posturing about that simply to get me to fix > the current situation? No. Rahul From jwboyer at jdub.homelinux.org Tue May 15 19:41:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 14:41:55 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <464A0C3C.2080308@fedoraproject.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <464902A2.60803@fedoraproject.org> <1179190799.19267.66.camel@vader.jdub.homelinux.org> <46490D21.6080703@fedoraproject.org> <20070515092610.6d0cae6b.bugs.michael@gmx.net> <464966A3.9090101@leemhuis.info> <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> <1179254946.3084.137.camel@zod.rchland.ibm.com> <464A01AE.70007@fedoraproject.org> <1179256129.3084.145.camel@zod.rchland.ibm.com> <464A0667.7030301@fedoraproject.org> <1179257603.3084.153.camel@zod.rchland.ibm.com> <464A0C3C.2080308@fedoraproject.org> Message-ID: <1179258115.3084.154.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 01:08 +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > > > > > You're still going to hold the general policy discussion though, > > correct? Since that is indeed something that needs to be done in the > > long run. > > Yes Great, thank you. josh From nicolas.mailhot at laposte.net Tue May 15 18:19:57 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 15 May 2007 20:19:57 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179238326.3084.64.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> <1179238326.3084.64.camel@zod.rchland.ibm.com> Message-ID: <1179253197.20659.6.camel@rousalka.dyndns.org> Le mardi 15 mai 2007 ? 09:12 -0500, Josh Boyer a ?crit : > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > and > > http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO BTW while some people wonder how to avoid testing/updates others would like to know how to push a package for testing/updates today (not covered in the linked pages) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwboyer at jdub.homelinux.org Tue May 15 19:45:37 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 14:45:37 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179253197.20659.6.camel@rousalka.dyndns.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> <1179238326.3084.64.camel@zod.rchland.ibm.com> <1179253197.20659.6.camel@rousalka.dyndns.org> Message-ID: <1179258337.3084.156.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 20:19 +0200, Nicolas Mailhot wrote: > Le mardi 15 mai 2007 ? 09:12 -0500, Josh Boyer a ?crit : > > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > > and > > > > http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO > > BTW while some people wonder how to avoid testing/updates others would > like to know how to push a package for testing/updates today (not > covered in the linked pages) Yes, I know. We're waiting on bodhi to show up. josh From jkeating at redhat.com Tue May 15 19:46:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 15:46:28 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179253197.20659.6.camel@rousalka.dyndns.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179238326.3084.64.camel@zod.rchland.ibm.com> <1179253197.20659.6.camel@rousalka.dyndns.org> Message-ID: <200705151546.29163.jkeating@redhat.com> On Tuesday 15 May 2007 14:19:57 Nicolas Mailhot wrote: > BTW while some people wonder how to avoid testing/updates others would > like to know how to push a package for testing/updates today (not > covered in the linked pages) There is no way to do it _today_. That bit of infrastructure is coming up soon. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From blizzard at redhat.com Tue May 15 19:51:50 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 15 May 2007 15:51:50 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <4649ED35.9030607@leemhuis.info> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> Message-ID: <1179258710.20155.23.camel@localhost.localdomain> I've been following this thread pretty casually. So here are my thoughts: 1. I don't think that anyone is asking anyone to apply RHEL-level criteria for package updates. 2. We want to have a nice update stream running. People feel like they are getting something that other people care about if there's constant motion. 3. We want to make sure some testing gets done on these packages. 4. We want to make sure that there's _some_ comment about why an update happens that end users might understand. Does that sound reasonable? --Chris From a.badger at gmail.com Tue May 15 19:51:01 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 May 2007 12:51:01 -0700 Subject: Request for comaintainers In-Reply-To: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> References: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> Message-ID: <1179258661.2746.8.camel@localhost.localdomain> Hi Jochen, On Tue, 2007-05-15 at 16:53 +0200, Jochen Schmitt wrote: > As a second question, what I have to do, that comaintainers can > recieve bugzilla messages and do builds for the packages? > Once you find someone interested in comaintaining a package, just follow the procedure listed here:: http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Tue May 15 19:57:13 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 15 May 2007 14:57:13 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179241379.3084.75.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> <200705151014.40688.jkeating@redhat.com> <1179238898.4735.500.camel@mccallum.corsepiu.local> <1179241379.3084.75.camel@zod.rchland.ibm.com> Message-ID: <1179259033.3084.160.camel@zod.rchland.ibm.com> On Tue, 2007-05-15 at 10:02 -0500, Josh Boyer wrote: > On Tue, 2007-05-15 at 16:21 +0200, Ralf Corsepius wrote: > > On Tue, 2007-05-15 at 10:14 -0400, Jesse Keating wrote: > > > On Tuesday 15 May 2007 09:56:28 Ralf Corsepius wrote: > > > > undocumented > > > > > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > > > > > > Really. > > Really, stop cheating. > > > > No word on release tags, > > no word on how to interface this into koji, > > no word on the freeze breaking "make build", > > ... > > > Try to keep up Ralf. > > > > I have decided to take a break from Fedora until things have settled. > > Are you orphaning your packages then? I just want things to be as clear > as possible to avoid any confusion. Ralf, if you're not orphaning your packages would you be agreeable to another maintainer submitting the request for you? If not, I'm going to have to use your: "I.e. I consider all these EVR breakages rel-eng's fault and it to be their job to handle them - period." comment as permission for rel-eng to fix it for this single instance. Some form of answer would be appreciated. josh From dominik at greysector.net Tue May 15 20:10:48 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 15 May 2007 22:10:48 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179256129.3084.145.camel@zod.rchland.ibm.com> References: <4649F123.8070701@fedoraproject.org> <1179251374.3084.115.camel@zod.rchland.ibm.com> <4649F429.2060006@fedoraproject.org> <1179252514.3084.121.camel@zod.rchland.ibm.com> <4649FA0C.6090502@fedoraproject.org> <1179253948.3084.133.camel@zod.rchland.ibm.com> <4649FFA9.1060904@fedoraproject.org> <1179254946.3084.137.camel@zod.rchland.ibm.com> <464A01AE.70007@fedoraproject.org> <1179256129.3084.145.camel@zod.rchland.ibm.com> Message-ID: <20070515201048.GD5928@ryvius.pekin.waw.pl> On Tuesday, 15 May 2007 at 21:08, Josh Boyer wrote: > On Wed, 2007-05-16 at 00:23 +0530, Rahul Sundaram wrote: > > >> That's all well and good for this specific instance but I am talking > > >> more about a general policy. How are you going to handle instances where > > >> maintainers refuse to cooperate? Step in and workaround them or consider > > >> the packages orphaned and pull them off? > > > > > > I have no energy to discuss some theoretical policy for a situation that > > > should hopefully not occur more than a few times. I'm not saying you're > > > wrong to address that, however. If you would like to have a discussion > > > on that, please start a new thread. It's not a discussion or policy > > > that will be finalized before F7 releases. > > > > I guess that depends on things like whether Ralf wants to follow the > > freeze process or not. > > No, it doesn't. Making a general policy to solve the current situation > will not be accomplished through the proper channels before Thursday, > which is when Deep Freeze occurs. Creating such a general policy > _cannot_ be rushed. It needs to be drafted, posted to -maintainers, > solicited for feedback, revised, and sent to FESCo. I think new packages shouldn't need additional approval beyond the usual review. > For this current situation, Ralf has already stated that he feels it is > rel-eng's responsibility to fix the upgrade paths for his packages. At > best, Ralf will submit a request himself. In the middle, he'll be > agreeable to another maintainer doing it on his behalf. At worst, > someone from rel-eng can do it with a bit of proper research. I am > prepared to do that as it seems to be the only way to solve this at the > moment. I have to admit I kind of liked the "rolling release" development model of Extras, though, personally, I tried to avoid major version bumps in anything but devel branch. I understand that the current change is part of the price to pay for the merge. Something along the lines of $ koji request-tag f7-final packagename would've been nice, though. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jkeating at redhat.com Tue May 15 20:17:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 16:17:18 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515201048.GD5928@ryvius.pekin.waw.pl> References: <4649F123.8070701@fedoraproject.org> <1179256129.3084.145.camel@zod.rchland.ibm.com> <20070515201048.GD5928@ryvius.pekin.waw.pl> Message-ID: <200705151617.18565.jkeating@redhat.com> On Tuesday 15 May 2007 16:10:48 Dominik 'Rathann' Mierzejewski wrote: > $ koji request-tag f7-final packagename > > > would've been nice, though. Patches accepted (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue May 15 20:32:33 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 22:32:33 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179248973.29594.9.camel@erebor.boston.redhat.com> References: <200705141710.20460.jkeating@redhat.com> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <200705151114.35814.jkeating@redhat.com> <20070515165714.GG2815@free.fr> <1179248973.29594.9.camel@erebor.boston.redhat.com> Message-ID: <20070515203233.GA2828@free.fr> On Tue, May 15, 2007 at 01:09:32PM -0400, Jeremy Katz wrote: > > From the point of view of the person maintaining the user visible update > tool, users *really do want to know* this information. And I get bugs As a user I don't necessarily want to know. I prefer that the maintainer do a more interesting things when he thinks that there is nothing to do about the update. > filed about the fact that Extras packages don't currently have this > information available. Does the bug submitter states that there should be something said for all and every package update? -- Pat From pertusus at free.fr Tue May 15 20:36:17 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 22:36:17 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179258710.20155.23.camel@localhost.localdomain> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> Message-ID: <20070515203617.GB2828@free.fr> On Tue, May 15, 2007 at 03:51:50PM -0400, Christopher Blizzard wrote: > I've been following this thread pretty casually. So here are my > thoughts: > > 3. We want to make sure some testing gets done on these packages. > > 4. We want to make sure that there's _some_ comment about why an update > happens that end users might understand. > > Does that sound reasonable? In some cases it is unneeded burden and bureaucracy. In many cases it makes sense, though. It should be there, but not mandatory, left to the maintainer best jugdement. -- Pat From pertusus at free.fr Tue May 15 20:40:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 22:40:10 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464A003C.4000307@hhs.nl> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <4649F3AF.2090306@hhs.nl> <4649F212.1030302@fedoraproject.org> <4649F652.9000203@hhs.nl> <4649F4FC.80405@fedoraproject.org> <4649FD6F.8030101@hhs.nl> <4649FB96.2000904@fedoraproject.org> <464A003C.4000307@hhs.nl> Message-ID: <20070515204010.GC2828@free.fr> On Tue, May 15, 2007 at 08:47:24PM +0200, Hans de Goede wrote: > > That is exactly what I was asking for, now the only remaining problem is > the definition of what is a critical bug fix. I think it would be best to > only allow updates-testing skipping by sending a request to rel-eng and > getting permission, much like this is done now for "breaking" the freeze. Once again, why not trust the maintainer best jugdement, why go mandatorily through unneeded advices? -- Pat From opensource at till.name Tue May 15 20:52:17 2007 From: opensource at till.name (Till Maas) Date: Tue, 15 May 2007 22:52:17 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705151617.18565.jkeating@redhat.com> References: <4649F123.8070701@fedoraproject.org> <20070515201048.GD5928@ryvius.pekin.waw.pl> <200705151617.18565.jkeating@redhat.com> Message-ID: <200705152252.18881.opensource@till.name> On Di Mai 15 2007, Jesse Keating wrote: > On Tuesday 15 May 2007 16:10:48 Dominik 'Rathann' Mierzejewski wrote: > > $ koji request-tag f7-final packagename > > > > > > would've been nice, though. > > Patches accepted (: After I found out that bodhi is a web-application, as soon as it is ready, it would be very helpful to link directly from koji to it, e.g. a link on http://koji.fedoraproject.org/koji/buildinfo?buildID=4418 that links to http://bodhi.fedoraproject.org/bodhi/new/915resolution-0.5.3-1.fc7 Regards, Till From pertusus at free.fr Tue May 15 20:48:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 22:48:00 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179250504.1459.46.camel@metroid.rdu.redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <20070515170227.GH2815@free.fr> <1179250504.1459.46.camel@metroid.rdu.redhat.com> Message-ID: <20070515204800.GD2828@free.fr> On Tue, May 15, 2007 at 01:35:04PM -0400, Will Woods wrote: > > So, what I hear you saying is that - regardless of whether users want it > or not - it's not worth *your* time to fill in the blanks on a short > message saying: I am not saying that. Not at all. I am saying that it should be up to the maintainer to decide whether it is better for the users to fill annoucements or work on another thing. And not only, most maintainers are benevolent so if somebody wants to make announcements when another maintainer doesn't want it could be possible, but once again not mandatory for the primary maintainer. Of course for security fixes and things like that the maintainer could be obliged to do an announcement, but if he is already packaging for fedora he will do it without being forced. > package-1.2.3-4.fc7 is a (bugfix,enhancement,security) update > which (adds the following features, fixes the following bugs): > ... > > We could even auto-fill the message from the changelog entries. Or.. > maybe you also have better things to work on than adding changelog > entries to your RPMS? Sometimes I don't add a changelog entry when it isn't useful. Still best judgement. > How about comments? Maybe I think I have better things to do than to > comment my code. Documentation, too. Sometimes it is better to work on the code and postpone documentation. There is no simple response to choices in the time allocation. > Look, here's the bottom line: people want to know what's changed when > you update packages on their systems. We can work together to make it > easy for you to provide this information. Let's work together to make > the infrastructure better rather than just refusing to use it. I am not refusing to use it I disagree with this being mandatory. I will use it, of course, I care about my users. But I also care about my time. And last we are capable of best judgement without being forced. -- Pat From sundaram at fedoraproject.org Tue May 15 21:07:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 02:37:06 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515203617.GB2828@free.fr> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> Message-ID: <464A20FA.2090101@fedoraproject.org> Patrice Dumas wrote: > On Tue, May 15, 2007 at 03:51:50PM -0400, Christopher Blizzard wrote: >> I've been following this thread pretty casually. So here are my >> thoughts: >> >> 3. We want to make sure some testing gets done on these packages. >> >> 4. We want to make sure that there's _some_ comment about why an update >> happens that end users might understand. >> >> Does that sound reasonable? > > In some cases it is unneeded burden and bureaucracy. In many cases it > makes sense, though. It should be there, but not mandatory, left to the > maintainer best jugdement. We have packaging guidelines today to help maintainers know how to package software and having a common understanding on what is required. We have a large collection of packages now and regressions are quite high. We need good QA guidelines. Simply relying on trust and best judgment on everything to individual maintainers doesn't scale well and is rather naive. Have you looked at how many major regressions we have for every release? If it is a important security or bug fix you can push it directly but on all other occasions it is very helpful if you could give some chance for people interested in testing to look at the update and check if there are any issues. Exceptions can go through release engineering/QA team. Updates in the general case would get pushed to updates-testing first and automatically move to general updates repo after a small amount of time. The maintainer can choose to extend the period or pull the package. It shouldn't be a significant additional burden at all. I will work with Will Woods to write down more specific details. Rahul From pertusus at free.fr Tue May 15 21:11:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 23:11:34 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464A20FA.2090101@fedoraproject.org> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> Message-ID: <20070515211134.GF2828@free.fr> On Wed, May 16, 2007 at 02:37:06AM +0530, Rahul Sundaram wrote: > > We have packaging guidelines today to help maintainers know how to > package software and having a common understanding on what is required. Those guidelines (except for very specific points like license) help having best practices, but may be ignored if in a specific situation it doesn't make sense, or it adds too much burden. For example I don't follow the guideline about asking FESCo for static libs because in general I know better and I don't want to make those people lose their time. For the changelog entries it is the same. And there are certainly other examples. > We have a large collection of packages now and regressions are quite > high. We need good QA guidelines. Simply relying on trust and best > judgment on everything to individual maintainers doesn't scale well and > is rather naive. It is not what I am saying. It would be very nice to have good QA guidelines. It would be a mistake to force maintainers against their best judgement. > Have you looked at how many major regressions we have > for every release? Not precisely. > If it is a important security or bug fix you can push it directly but on > all other occasions it is very helpful if you could give some chance for > people interested in testing to look at the update and check if there > are any issues. Indeed. That is sensible best practices. > Exceptions can go through release engineering/QA team. I don't think this is useful. The maintainer will always know better (with the knowledge of the QA guidelines) and in case he doesn't know he should be able to ask by himself. > Updates in the general case would get pushed to updates-testing first > and automatically move to general updates repo after a small amount of > time. But it should be possible for the maintainer to chose to push it to the repo immediatly based on his best judgement. In the cases when he did a mistake, somebody with the right powers could still remove the package but I am sure that this would be very rare. If it is not rare then we are not selecting the maintainers enough. > The maintainer can choose to extend the period or pull the > package. It shouldn't be a significant additional burden at all. I will > work with Will Woods to write down more specific details. -- Pat From sundaram at fedoraproject.org Tue May 15 21:34:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 03:04:08 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515211134.GF2828@free.fr> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> Message-ID: <464A2750.7040805@fedoraproject.org> Patrice Dumas wrote: >> Have you looked at how many major regressions we have >> for every release? > > Not precisely. Please do. This is a QA process and to understand the need for it you need to know what drives it. Spend sometime reading through end users forums. >> Exceptions can go through release engineering/QA team. > > I don't think this is useful. The maintainer will always know better > (with the knowledge of the QA guidelines) and in case he doesn't know > he should be able to ask by himself. You can't rely on maintainers always knowing better. Again this doesn't scale. In the cases when he did a > mistake, somebody with the right powers could still remove the package > but I am sure that this would be very rare. If it is not rare then we > are not selecting the maintainers enough. For the major portion of Fedora, we don't select maintainers. They choose to volunteer. When mistakes are made a lot of end users would be affected and it would be too late to be removing packages. In the general case packages would automatically be pushed. If you are going to request exceptions that would be a relatively rare thing and doesn't add much of a burden. A burden which is necessary because it provides us a chance to reduce broken stuff getting pushed out. Rahul From pertusus at free.fr Tue May 15 21:36:42 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 23:36:42 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464A2750.7040805@fedoraproject.org> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <464A2750.7040805@fedoraproject.org> Message-ID: <20070515213642.GG2828@free.fr> On Wed, May 16, 2007 at 03:04:08AM +0530, Rahul Sundaram wrote: > > Please do. This is a QA process and to understand the need for it you > need to know what drives it. Spend sometime reading through end users > forums. I don' have the time to do so. But I experience the regressions as a user though. > You can't rely on maintainers always knowing better. Again this doesn't > scale. We have to, otherwise it doesn't scale. Having to go through release maintainers, in my opinion, scales less well than educating people we sponsor. > For the major portion of Fedora, we don't select maintainers. They > choose to volunteer. No, we sponsor them, that means that we select them. > When mistakes are made a lot of end users would be > affected and it would be too late to be removing packages. > > In the general case packages would automatically be pushed. If you are > going to request exceptions that would be a relatively rare thing and > doesn't add much of a burden. A burden which is necessary because it > provides us a chance to reduce broken stuff getting pushed out. I don't think it is necessary to go through a team for pushing things out. Of course it could be exceptions and the default could be to push things in the uppdate repo where they are released automatically as you describe above, but tthis should only be default not something mandatory. As a side note, what should be mandatory would be for sponsors to watch the people they sponsored (not for their whole life, but until the sponsor feels that the sponsoree is knowlegable enough), but that's another issue. -- Pat From jkeating at redhat.com Tue May 15 21:48:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 17:48:20 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515213642.GG2828@free.fr> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> Message-ID: <200705151748.20520.jkeating@redhat.com> On Tuesday 15 May 2007 17:36:42 Patrice Dumas wrote: > > In the general case packages would automatically be pushed. If you are > > going to request exceptions that would be a relatively rare thing and > > doesn't add much of a burden. A burden which is necessary because it > > provides us a chance to reduce broken stuff getting pushed out. > > I don't think it is necessary to go through a team for pushing things > out. Of course it could be exceptions and the default could be to push > things in the uppdate repo where they are released automatically as you > describe above, but tthis should only be default not something > mandatory. You do realize that prior to the merger you were _still_ going through somebody to get your pushes to happen. The folks that were doing the Extras pushes still had to make sure the repos were consistant, still had to sign the packages, and make the bits go. Only now we're asking you to provide us with some extra information about the updates so that we can make better decisions about what to release and what to hold back, or how quickly we need to do a push. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue May 15 21:53:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 15 May 2007 23:53:55 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464A2750.7040805@fedoraproject.org> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <464A2750.7040805@fedoraproject.org> Message-ID: <20070515215355.GA11742@neu.nirvana> On Wed, May 16, 2007 at 03:04:08AM +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: > > >>Have you looked at how many major regressions we have > >>for every release? > > > >Not precisely. > > Please do. This is a QA process and to understand the need for it you > need to know what drives it. Spend sometime reading through end users > forums. The question is: how do these regression distribute among Core and Extras (based on weight like number of packages in repo and also number of packages used by users of course). I'm under the impression that the regressions that made most of the noise were part of Core and that already had the QA systems being discussed in place (updates-testing, mandatory announcements etc). And OTOH we decide that packages don't need rebuilds pushing any broken package out there to break in users' hands instead of during the development cycle and OTOH we raise burocratic hurdles w/o a real gain. Ask yourself: Will an announcement of a package update really increate package *quality*, e.g. add to a better QA? Not really. Don't understand me wrong: I like package update announcements. But they will not magically increase package quality and reduce regressions. Same for an unused updates-testing repo. A better QA? Force package maintainers to push their packages into updates-testing and have them enable updates-testing *on their own systems*. That way you get a couple of hundreds skilled people actually using updates-testing ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue May 15 21:54:14 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 May 2007 23:54:14 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151748.20520.jkeating@redhat.com> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> Message-ID: <20070515215414.GJ2828@free.fr> On Tue, May 15, 2007 at 05:48:20PM -0400, Jesse Keating wrote: > > You do realize that prior to the merger you were _still_ going through > somebody to get your pushes to happen. The folks that were doing the Extras Of course I was not saying that there was something magical happening, but that there was no need to notify. Once again I am not against notifying, but against having to notify being mandatory. > pushes still had to make sure the repos were consistant, still had to sign > the packages, and make the bits go. Only now we're asking you to provide us > with some extra information about the updates so that we can make better > decisions about what to release and what to hold back, or how quickly we need > to do a push. You shouldn't be doing these decisions based on the information I provide, you should do what I have decided (regarding whether the releases should be pushed immediately, go to the testing repo), and ask for information in case you have noticed that I was doing something bad. -- Pat From sundaram at fedoraproject.org Tue May 15 22:02:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 May 2007 03:32:50 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515215355.GA11742@neu.nirvana> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <464A2750.7040805@fedoraproject.org> <20070515215355.GA11742@neu.nirvana> Message-ID: <464A2E0A.7000300@fedoraproject.org> Axel Thimm wrote: > Ask yourself: Will an announcement of a package update really increate > package *quality*, e.g. add to a better QA? Not really. I was talking about updates-testing and not update announcement. Rahul From jkeating at redhat.com Tue May 15 22:15:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 18:15:43 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515215414.GJ2828@free.fr> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> Message-ID: <200705151815.44128.jkeating@redhat.com> On Tuesday 15 May 2007 17:54:14 Patrice Dumas wrote: > You shouldn't be doing these decisions based on the information I > provide, you should do what I have decided (regarding whether the > releases should be pushed immediately, go to the testing repo), > and ask for information in case you have noticed that I was doing > something bad. I didn't say anything to the counter. However if you ask for a non security update for foo, I may wait until later in the afternoon and push a bunch at once. However if you ask for a security update for bar, I may push immediately, regardless of what repo it goes into. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue May 15 22:20:14 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 16 May 2007 00:20:14 +0200 Subject: ppc64 and own packages? Message-ID: <20070516002014.18c1abd3@localhost.localdomain> Hi. I'm sorry if this is a stupid question: I've noticed that my own packages [1] are not build for ppc64 after importing into koji. There was no update for them and also no advice for an mass rebuild. So they are at least +1 months old. Is this intended or did I missed something? Sebastian [1] http://koji.fedoraproject.org/koji/userinfo?userID=260 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Tue May 15 22:18:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 00:18:08 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151815.44128.jkeating@redhat.com> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> <200705151815.44128.jkeating@redhat.com> Message-ID: <20070515221808.GK2828@free.fr> On Tue, May 15, 2007 at 06:15:43PM -0400, Jesse Keating wrote: > On Tuesday 15 May 2007 17:54:14 Patrice Dumas wrote: > > You shouldn't be doing these decisions based on the information I > > provide, you should do what I have decided (regarding whether the > > releases should be pushed immediately, go to the testing repo), > > and ask for information in case you have noticed that I was doing > > something bad. > > I didn't say anything to the counter. However if you ask for a non security > update for foo, I may wait until later in the afternoon and push a bunch at > once. However if you ask for a security update for bar, I may push > immediately, regardless of what repo it goes into. Ok, I see what you mean. Indeed it would be nice if it was possible to ask for a push as soon as possible, you are right. -- Pat From opensource at till.name Tue May 15 22:44:57 2007 From: opensource at till.name (Till Maas) Date: Wed, 16 May 2007 00:44:57 +0200 Subject: ppc64 and own packages? In-Reply-To: <20070516002014.18c1abd3@localhost.localdomain> References: <20070516002014.18c1abd3@localhost.localdomain> Message-ID: <200705160045.00051.opensource@till.name> On Mi Mai 16 2007, Sebastian Vahl wrote: > I'm sorry if this is a stupid question: I've noticed that my own > packages [1] are not build for ppc64 after importing into koji. There > was no update for them and also no advice for an mass rebuild. So they > are at least +1 months old. > > Is this intended or did I missed something? Packages with tag "fe7-merge" are only copied from plague. To get a ppc64 build you need to increase the version or release of your packages and build them manually. Maybe there is also a way to only build them for ppc64, but I do not know it. Regards, Till From jkeating at redhat.com Tue May 15 23:29:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 May 2007 19:29:31 -0400 Subject: ppc64 and own packages? In-Reply-To: <20070516002014.18c1abd3@localhost.localdomain> References: <20070516002014.18c1abd3@localhost.localdomain> Message-ID: <200705151929.35222.jkeating@redhat.com> On Tuesday 15 May 2007 18:20:14 Sebastian Vahl wrote: > I'm sorry if this is a stupid question: I've noticed that my own > packages [1] are not build for ppc64 after importing into koji. There > was no update for them and also no advice for an mass rebuild. So they > are at least +1 months old. > > Is this intended or did I missed something? Most if not all "Extras" packages had a ppc64 build done on the side and imported. This happened somewhat silently, so you'd have to check your package again to see if there is a ppc64 rpm for it now. If there isn't a ppc64 build, you'll have to do as Till suggests, bump, build, and request tagging for f7-final. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Tue May 15 23:43:13 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 May 2007 16:43:13 -0700 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515211134.GF2828@free.fr> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> Message-ID: <1179272593.2746.89.camel@localhost.localdomain> On Tue, 2007-05-15 at 23:11 +0200, Patrice Dumas wrote: > On Wed, May 16, 2007 at 02:37:06AM +0530, Rahul Sundaram wrote: > > > > We have packaging guidelines today to help maintainers know how to > > package software and having a common understanding on what is required. > > Those guidelines (except for very specific points like license) help > having best practices, but may be ignored if in a specific situation it > doesn't make sense, or it adds too much burden. > > For example I don't follow the guideline about asking FESCo for static > libs because in general I know better and I don't want to make those > people lose their time. For the changelog entries it is the same. And > there are certainly other examples. > I think you're going to have to rethink your position a bit. Unless a guideline is marked as a "should" it is mandatory. If you disagree with something the guidelines say is a must, the proper thing to do is to get the guideline changed.[1]_ For changelogs, the guidelines say: "Every time you make changes, that is, whenever you increment the E-V-R of a package, add a changelog entry." This means you must write a changelog entry. The reasons are given in the guidelines [2]_. For static libraries, the guidelines recognize that there may be instances where static libraries are desirable. If you want to either provide static libraries in a subpackage or to link against static libraries you must ask FESCo for permission. This check was written for several reasons: 1) static libraries are a security hazard and there is a strong desire to keep the libraries from being linked into packages provided by Fedora. This check helps FESCo and the packaging committee enforce this. 2) The Packaging Committee realized that there are packages that need to contravene this policy but not how many. If there are hundreds of libraries in Fedora requesting to ship static libraries then the guideline must be revised to accommodate them. If it's only a dozen then having exceptions for those packages is sufficient. 3) The Packaging Committee realized that this draft could be made better if we could draft a statement that covered the valid cases without letting packages without sufficient reasons in. However we didn't have a large enough sample of valid packages to be able to write that yet. By having this reported we would be able to gather information on what rule could be made to fit this. Deciding "not to bother FESCo" with this is not saving us time; it is making it so someone down the line has to spend time finding which packages are linking against static libraries without an exemption and figure out what the proper fix is. -Toshio [1]_: Although this has always been the view of the packaging committee, it is apparent that it has sometimes been a source of confusion. (Perhaps the name "Packaging Guidelines" is unfortunate in this regard but no one has yet been motivated to ask for a change in name.) We did add an intro paragraph to the guidelines a few weeks ago that clarified this and other issues. The relevant portion is:: ''' The Packaging Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your package should be exempt from part of the Guidelines, please bring the issue to the Fedora Packaging Committee. ''' [2]_: http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs -------------- 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 kwizart at gmail.com Wed May 16 00:30:57 2007 From: kwizart at gmail.com (KH KH) Date: Wed, 16 May 2007 02:30:57 +0200 Subject: Request for comaintainers In-Reply-To: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> References: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> Message-ID: 2007/5/15, Jochen Schmitt : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I'm search comaintainsers for this packages: > > - - aplus-fsf > - - blender Hello I sure blender might bring some interest! It has been recently updated to 2.44 (with a bugfix release for 2.43 about x86_64) I will start to do some work with these version on x86_64... (quite sure there is a need to break the deep freeze about this package and x86_64 support...) I currently maintain aqsis so i'm interested in blender and how it can interact with it... > - - crossvc > - - gnu-smalltalk > - - gprolog > - - highlight > - - inadyn > - - kyum > - - lightning > - - luma > - - pdftk > - - steghide > - - stellarium > - - suck I have some interest in stellarium but i know less others ones... (i will quick look some of them...) Nicolas (kwizart) PS: About kyum, Someone on the french forum reported that it has deleted my repository definition: kwizart.repo. I will sanity check it ... But i'm not a kde user usually... From a.badger at gmail.com Wed May 16 01:46:23 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 May 2007 18:46:23 -0700 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <46434905.8020407@leemhuis.info> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> <1178813454.3570.39.camel@localhost.localdomain> <46434905.8020407@leemhuis.info> Message-ID: <1179279983.2746.137.camel@localhost.localdomain> On Thu, 2007-05-10 at 18:32 +0200, Thorsten Leemhuis wrote: > Tom "spot" Callaway schrieb: > > On Thu, 2007-05-10 at 10:41 -0500, Josh Boyer wrote: > >> On Thu, 2007-05-10 at 09:07 -0500, Tom "spot" Callaway wrote: > >>> On Thu, 2007-05-10 at 10:51 +0200, Christian Iseli wrote: > >>>> Dear all, > >>>> > >>>> On Wed, 09 May 2007 17:05:05 -0400, Brian Pepple wrote: > >>>>> Anyway, please find below the list of > >>>>> topics that are likely to come up in the next FESCo meeting that is > >>>>> scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on > >>>>> irc.freenode.org: > >>>> I won't be able to attend: I have voluntary firefighter training that I > >>>> need to attend... > >>>> > >>>> In case the zope thing comes up again, here is my current view: > >>>> - I'm not in favor of a compat-python2.4 package: > >>>> o python maintainer doesn't want it > >>>> o not in line with a bleeding edge distro > >>>> o does not encourage other packages to update to newer version > >>>> - I could agree to a runzope package, or maybe even better a > >>>> zope-runtime sub-package > >>> Since I probably won't be there, due to the RH Summit, my thoughts (and > >>> votes if it comes to it): > >>> - No compat-python2.4 package > >> Spot, could you clarify this a bit? Christian stated his opinion on > >> both compat-python2.4 (a generic compat package for the distro) and > >> "runzope" (python 2.4 packaged inside of the zope package). > > I'm not against runzope, per-se, but I'd much much rather see an effort > > to bring zope to current python. > > > > My biggest concern with runzope packaging ideaology is that we'll leave > > it at that, and not fix the real problem. > > Well, what does that mean for compat-packages in general? Should each of > those have a limited life time as well? Or do we need other rules like > "packages from the repo are not allowed to use or link against compat > packages in the devel tree at release time of a Fedora release"? > > I just want consistency. We ship about 40 pacakges afaics and we should > apply the same rules to all out packages. I fail to understand why > python is so special. It's IMHO not just about "python for zope": people > might have apps from other sources compiled against python-2.4 installed > on their system -- shipping a compat-python24 for one release gives them > time to get those apps running after a update to F7 so they can migrate > their software to python 2.5 over the next half year until we ship F8. > I'd be against a rule that very broadly banned compat packages. compat-* packages can be useful and have minimal impact for packagers. Jeremy's arguments about compat-python adding to the maintenance burden for the python-2.5 maintainer are only somewhat valid to me. There very well could be bugs mistargeted against the current version of the package instead of the compat- version but if it's actually causing us problems, that's a failure in how we form channels of communication between developers and how we guide end users into making bug reports that we need to address regardless. Much more telling to me is that python is a framework. Building a viable python2.4 is much more than building a compat-python2.4 package and calling it done. We have to rebuild all our python modules for python2.4 as well. Most of those will be easy. Especially as long as those packages are also available in FC6. However, not everything will be -- and the more releases we get from python2.4 being /usr/bin/python the farther we will get from having packages that just work. So I can see a justification for excluding compat-python on these grounds. These arguments would also apply to packages like perl, php, and ruby where we would need to maintain a whole slew of additional compat packages. That said, I'm not currently in favor of outright excluding compat-* for these either. I think a sufficiently dedicated group of packagers *could* do a good job of maintaining the packages. So instead of having a policy that denies people the opportunity to do this we should be coming up with a set of expectations that we have for a group that is attempting to do something like this. Do we want them to prove the idea is valid in a separate download repository first? (Work could still occur within Fedora cvs/builders but the builds would be pushed to a separate repository.) Do we want to specify how many packagers must be involved? Do we want to make sure there's some method that they use to communicate with the maintainers of the non-compat versions of their packages? In other words, instead of saying, "No, we won't let you do this no matter how dedicated you think you are to making it happen", come up with a skeleton that says, "We don't think your project will succeed (and that will reflect poorly on the rest of Fedora) unless you have a plan to deal with these issues. Here are the issues and some possible solutions that we think would mitigate them." These policies could share a lot with other very large projects unrelated to compat- packages. New official spins, a new legacy project, official secondary arches, etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpepple at fedoraproject.org Wed May 16 02:13:32 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 15 May 2007 22:13:32 -0400 Subject: FESCo Meeting Summary for 2007-05-10 Message-ID: <1179281612.5749.0.camel@lincoln> Members Present: * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) Absent: * Christian Iseli (c4chris) * Tom Callaway (spot) * Rex Dieter (rdieter) * Warren Togami (warren) * Jeremy Katz (jeremy) == Summary == * No major decisions made this week, since several of the FESCo members where at the RedHat summit. = EPEL Meeting summaries = * EPEL meeting summaries will be sent to the maintainers and FESCo mailing lists. FESCo members have 72 hours to make any objections known on a public mailing list (in this case the maintainers list). = EPEL Repotag = * Thorsten Leemhuis wanted FESCo members opinion regarding the use of repotags. The general concensus from the members present was that they didn't care for them. = Misc = * Discussed the package review for xu4. The FESCo members present didn't have any issues with the solution used for downloading the game data, since it was basically the same solution used for the codec buddy. * a handfull of stuff needs to get done with bodhi. I'm locking myself in my room this weekend until it gets done :) it will be deployed this weekend. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070510 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Wed May 16 03:41:14 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 15 May 2007 23:41:14 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515204800.GD2828@free.fr> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <20070515170227.GH2815@free.fr> <1179250504.1459.46.camel@metroid.rdu.redhat.com> <20070515204800.GD2828@free.fr> Message-ID: <1179286874.4180.3.camel@localhost.localdomain> On Tue, 2007-05-15 at 22:48 +0200, Patrice Dumas wrote: > I am not saying that. Not at all. I am saying that it should be up to > the maintainer to decide whether it is better for the users to fill > annoucements or work on another thing. > > And not only, most maintainers are benevolent so if somebody wants > to make announcements when another maintainer doesn't want it could > be possible, but once again not mandatory for the primary maintainer. > Of course for security fixes and things like that the maintainer > could be obliged to do an announcement, but if he is already > packaging for fedora he will do it without being forced. I think it is a bit silly to claim some "maintainer privilege" for this (which is actually a very important part of ensuring a good update experience for users), when we are at the same time force packagers to justify every comma they may have misplaced in a spec file during package reviews (which has very little bearing on the user experience). There is some incongruence here. From rc040203 at freenet.de Wed May 16 03:47:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 05:47:24 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179250504.1459.46.camel@metroid.rdu.redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <20070515170227.GH2815@free.fr> <1179250504.1459.46.camel@metroid.rdu.redhat.com> Message-ID: <1179287244.4735.581.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 13:35 -0400, Will Woods wrote: > On Tue, 2007-05-15 at 19:02 +0200, Patrice Dumas wrote: > > On Tue, May 15, 2007 at 12:11:05PM -0400, Will Woods wrote: > > > On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > > > > > We will have to work slightly harder in order to Do The Right Thing for > > > our users, to ensure package sanity and overall distribution stability. > > > Those are our goals, and I hope you'll agree that they're worth working > > > for. > > > > Indeed, but it isn't the point. Sometimes doing the right thing is not > > losing time when there are better things to work on. > > So, what I hear you saying is that - regardless of whether users want it > or not - it's not worth *your* time to fill in the blanks on a short > message saying: > > package-1.2.3-4.fc7 is a (bugfix,enhancement,security) update > which (adds the following features, fixes the following bugs): > ... Yes, because your are forcing me to waste my volunteered and unpaid time on something hardly anybody needs. > We could even auto-fill the message from the changelog entries. If you really want such messages, yes, this is the only practicable way not imposing usability regressions on maintainers. > Look, here's the bottom line: people want to know what's changed when > you update packages on their systems. Wrong. Some people want to know. The majority runs "yum update" and doesn't even know they have an option to know. > We can work together to make it > easy for you to provide this information. Let's work together to make > the infrastructure better rather than just refusing to use it. Your first step should be to keep Fedora's contribution infrastructure as simple as possible otherwise Fedora will be loosing contributors. Ralf From rc040203 at freenet.de Wed May 16 03:55:03 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 05:55:03 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179249933.1459.35.camel@metroid.rdu.redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> Message-ID: <1179287703.4735.589.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 13:25 -0400, Will Woods wrote: > On Tue, 2007-05-15 at 18:31 +0200, Ralf Corsepius wrote: > > On Tue, 2007-05-15 at 12:11 -0400, Will Woods wrote: > > > On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: > > > > Will there be a way to short-circuit the announcement and just update, > > > > like it was possible before? > > > > > > Holy Zod, no. No no no. Very no. > > > > > > There will be no more silent updating of packages without explanation > > > or at least a *chance* for testing. > > What you call testing, I call locking out updates and bug-fixes > > == regression > > Excuse me? Who said anything about locking out updates or bug fixes? It's what already is happening due to this new freaking release procedure. > I'm > just asking that packages spend a few days in a -testing repository - > which is open to the entire world - to be sanity tested by QA and > interested users before going to the updates repo. You are not able to test 1000s of packages nor are you able to have tests for them. All what you might be able to do is performing some "rpm consistency checks", but that's all. > How does that lock out *anything*? What are you even talking about? * E.g. about API, SONAME changes, compat-packages etc. If you're going to freeze APIs, SONAMEs etc. you're locking out packages. * By forcing maintainers to fill out forms or similar steps, you are imposing additional load on maintainers. I for one don't have any time available to waste on this kind of kid stuff. As a consequence you'll be facing me not upgrading packages. > Where are you drawing these ridiculous conclusions from? You are telling me you are "testing" - I say, _you_ can't test, because this is technically impossible. > > > Yeah, I know this makes putting out updates slightly harder, > > > > == regression > > You keep using that word. I do not think it means what you think it > does. No, I really mean 'regression": You are breaking and complicating what has been functional and simple before => "technically harder == usability regression". > Let me get this straight: You think that being able to cram changes down > the throats of ~2mil users without justification or testing is a > *feature*, and that requiring (world-accessible) testing is a *bug*. Yes. It's a waste of time, because * a "responsible/conscious maintainer" is supposed to test his stuff in advance and should be better knowledgeable about a package's details than anybody else. If he isn't, he probably should not maintain this package. * a mandatory "update-testing" is superfluous in the vast majority of cases, an optional "update-testing" can make sense in _some_ (few) cases. * a mandatory "update-testing" repo is of very limited use to the majority of users, because only those facing issues should use it for "selected updates". Ordinary users should not use it all. Un-educated users however will activate it. > > > but in my > > > opinion the fact that we ever allowed this at all was a massive > > > oversight, not a design feature. > > > > I disagree. Release early, release often is a feature, now you are > > spoiling one of the fundamental working principles of Fedora. > > How is it spoiling anything? Delays, bloat, complexity, bureaucracy, featuritis. > The packages are still available > immediately after build, just like before. I think you have > misunderstood what we're talking about here. Possibly, because RH once again seems to have failed to communicate what THEIR plan is and seems to be pressing something which doesn't seem to be clear to themselves onto the community. At the moment I am primarily referring to this nonsensical regressions this new release flow and koji impose on my packages. I see regressions all over the place: What once was simple, now requires additional effort and wastes my time. Ralf From tibbs at math.uh.edu Wed May 16 03:58:21 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 May 2007 22:58:21 -0500 Subject: No Packaging Committee meeting 2007-05-15 Message-ID: There was no FPC meeting today due to lack of quorum. - J< From dev at nigelj.com Wed May 16 04:03:31 2007 From: dev at nigelj.com (Nigel Jones) Date: Wed, 16 May 2007 16:03:31 +1200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179287703.4735.589.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> Message-ID: <464A8293.3070609@nigelj.com> Ralf Corsepius wrote: > On Tue, 2007-05-15 at 13:25 -0400, Will Woods wrote: >> On Tue, 2007-05-15 at 18:31 +0200, Ralf Corsepius wrote: >>> On Tue, 2007-05-15 at 12:11 -0400, Will Woods wrote: >>>> On Tue, 2007-05-15 at 17:00 +0200, Patrice Dumas wrote: >>>>> Will there be a way to short-circuit the announcement and just update, >>>>> like it was possible before? >>>> Holy Zod, no. No no no. Very no. >>>> >>>> There will be no more silent updating of packages without explanation >>>> or at least a *chance* for testing. >>> What you call testing, I call locking out updates and bug-fixes >>> == regression >> Excuse me? Who said anything about locking out updates or bug fixes? > It's what already is happening due to this new freaking release > procedure. Yes, we call that a freeze and the freeze policy has been made loud and clear to everyone it's not a case of locking out updates, it's making sure that F7 'Gold' is fairly stable, then QA can concentrate on other updates... N.J. From wtogami at redhat.com Wed May 16 04:32:10 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 May 2007 00:32:10 -0400 Subject: Updates System In-Reply-To: <1179287703.4735.589.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> Message-ID: <464A894A.3050308@redhat.com> Ralf Corsepius wrote: > Possibly, because RH once again seems to have failed to communicate what > THEIR plan is and seems to be pressing something which doesn't seem to > be clear to themselves onto the community. > > At the moment I am primarily referring to this nonsensical regressions > this new release flow and koji impose on my packages. I see regressions > all over the place: What once was simple, now requires additional effort > and wastes my time. > > Ralf Ralf, You are going way overboard in escalating what is entirely a non-issue. All package updates going out after F7 release will need to go through the update system. Pushing packages in this way is NOT a horrible burden that you make it out to be. This is only formalizing a process that was very uncontrolled in the past only because we didn't have time to write anything like this. Fact of the matter is, we were doing poorly in Fedora in the past without package update announcements for Extras. Sure, this was harmless in most cases, but in the case of security this was quite possibly dangerous and not in the interest of spreading necessary awareness to our community. Today Core updates happen using this update system. It is a smooth and formal process. 1) Maintainer checks changes into CVS branch. 2) Maintainer builds. 3) Maintainer tests that build. 4) Maintainer fills out the form with the N-V-R, optional security (yes/no), optional Bug numbers fixed, and some fills in some details of what the update is about, then chooses updates or updates-testing. 5) Submit, where security and/or rel-eng team pushes it through. I personally don't care what the update announcement part says. If you truly have nothing meaningful to say about it, I personally don't care if you write: - Update to new version - Updating because I feel like it - Bump Bodhi really isn't that bad currently, and I suspect we will make further improvements down the line to more smoothly integrate it into other parts of the package process. If there is enough demand, we might even be able to write an optional TUI interface to accommodate users who want to avoid a web driven push process. This is necessary and we are going to do it. I believe after working out some initial kinks, participants will realize how much it really doesn't suck. However, if you don't wish to participate then you are free to leave. Warren Togami wtogami at redhat.com From Christian.Iseli at licr.org Wed May 16 06:32:19 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 16 May 2007 08:32:19 +0200 Subject: Plan for tomorrows (20070510) FESCO meeting In-Reply-To: <1179279983.2746.137.camel@localhost.localdomain> References: <1178744705.5807.6.camel@lincoln> <20070510105147.47f4af4b@ludwig-alpha.unil.ch> <1178806079.3570.35.camel@localhost.localdomain> <1178811676.22802.42.camel@zod.rchland.ibm.com> <1178813454.3570.39.camel@localhost.localdomain> <46434905.8020407@leemhuis.info> <1179279983.2746.137.camel@localhost.localdomain> Message-ID: <20070516083219.7cef2db3@ludwig-alpha.unil.ch> On Tue, 15 May 2007 18:46:23 -0700, Toshio Kuratomi wrote: > In other words, instead of saying, "No, we won't let you do this no > matter how dedicated you think you are to making it happen", come up > with a skeleton that says, "We don't think your project will succeed > (and that will reflect poorly on the rest of Fedora) unless you have a > plan to deal with these issues. Here are the issues and some possible > solutions that we think would mitigate them." I like the way this sounds, but the devil's in the details. So I'd definitely like to see some kind of draft policy outlining aspects like: - who will help triage bugs in and make sure they do not target compat- - same with security issues - who will actually test the systems where both and compat- are installed and see if nothing "funny" happens and how to go about testing it I'm fine with having compat packages living a long life, as long they they do not hinder the rest of the project. C From fedora at leemhuis.info Wed May 16 07:10:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 May 2007 09:10:46 +0200 Subject: FESCo Meeting Summary for 2007-05-10 In-Reply-To: <1179281612.5749.0.camel@lincoln> References: <1179281612.5749.0.camel@lincoln> Message-ID: <464AAE76.1070109@leemhuis.info> Hi All! On 16.05.2007 04:13, Brian Pepple wrote: > = EPEL Repotag = > * Thorsten Leemhuis wanted FESCo members opinion regarding the use > of repotags. The general concensus from the members present was > that they didn't care for them. Sorry, but from looking at the full logs with statements like >[...] * f13 peeks in, -1 on a repotag (again). >[...] * dgilmore -1 >[...] 0. i think it's silly, but that's EPELs choice >[...] -0.5. it's the wrong solution. not sure whether fesco wants to let epel be wrong on their own :) >[...] and some others (see full log) I would make the summary statement more a "FESCO members want to leave the decision to the EPEL Steering Committee, but are not in favour of repotags." CU thl From rc040203 at freenet.de Wed May 16 07:19:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 09:19:08 +0200 Subject: Updates System In-Reply-To: <464A894A.3050308@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> Message-ID: <1179299948.4735.622.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 00:32 -0400, Warren Togami wrote: > Ralf Corsepius wrote: > > Possibly, because RH once again seems to have failed to communicate what > > THEIR plan is and seems to be pressing something which doesn't seem to > > be clear to themselves onto the community. > > > > At the moment I am primarily referring to this nonsensical regressions > > this new release flow and koji impose on my packages. I see regressions > > all over the place: What once was simple, now requires additional effort > > and wastes my time. > > > > Ralf > > Ralf, > > You are going way overboard in escalating what is entirely a non-issue. What you consider "non-issue", I consider a fundamental flaw in work-flow causing harm to community's involvment into Fedora. That's why I am making a fuzz about it. > All package updates going out after F7 release will need to go through > the update system. Pushing packages in this way is NOT a horrible > burden that you make it out to be. Update 40 packages at once and you'll probably notice why I consider this to be a crack ridden work-flow. 2 steps more per package and one form per package demonstrates the flaws of this workflow. > This is only formalizing a process > that was very uncontrolled in the past only because we didn't have time > to write anything like this. I don't see any thing uncontrolled. To the contrary, I perceive your new work-flow to suffer from "Prussian State Officer" (Germ. proverb. "Preussische Beamtenmentalit?t") mentality. > Fact of the matter is, we were doing poorly in Fedora in the past > without package update announcements for Extras. Sure, this was > harmless in most cases, but in the case of security this was quite > possibly dangerous and not in the interest of spreading necessary > awareness to our community. > > Today Core updates happen using this update system. It is a smooth and > formal process. This might be your vision - It definitely is not mine. 0) maintainer tests package's functionality. > 1) Maintainer checks changes into CVS branch. > 2) Maintainer builds. > 3) Maintainer tests that build. > 4) Maintainer fills out the form with the N-V-R, optional security > (yes/no), optional Bug numbers fixed, and some fills in some details of > what the update is about, then chooses updates or updates-testing. > 5) Submit, where security and/or rel-eng team pushes it through. Now where in this scheme is Will Woods? I don't see him testing anything. All I see is more bureaucracy and more manual steps than before. > This is necessary and we are going to do it. Yes, you think it's necessary and you apparently don't give a damn about other people's opinion - poor. > I believe after working > out some initial kinks, participants will realize how much it really > doesn't suck. ... if you think so, I could not disagree more. > However, if you don't wish to participate then you are free to leave. I did not expect any different answer from a person who could not refrain from attacking and offending me in rude language, before. You will have to understand that the bridges between you and me are burnt. Ralf From j.w.r.degoede at hhs.nl Wed May 16 07:37:11 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 16 May 2007 09:37:11 +0200 Subject: Updates System In-Reply-To: <1179299948.4735.622.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> Message-ID: <464AB4A7.6040209@hhs.nl> Ralf Corsepius wrote: > On Wed, 2007-05-16 at 00:32 -0400, Warren Togami wrote: >> Today Core updates happen using this update system. It is a smooth and >> formal process. > 0) maintainer tests package's functionality. >> 1) Maintainer checks changes into CVS branch. >> 2) Maintainer builds. >> 3) Maintainer tests that build. >> 4) Maintainer fills out the form with the N-V-R, optional security >> (yes/no), optional Bug numbers fixed, and some fills in some details of >> what the update is about, then chooses updates or updates-testing. >> 5) Submit, where security and/or rel-eng team pushes it through. > > Now where in this scheme is Will Woods? I don't see him testing > anything. All I see is more bureaucracy and more manual steps than > before. > As someone who maintains 125+ packages, I would like to show some support for Ralf's point of view. I'm very proud of the fact that I not only maintain 125+ packages, but also have 0 yes _zero_ open bugs against them (most of the time), call me Hans "zero open bugs" de Goede if you want :) However sometime real life intervenes and I cannot work on Fedora stuff for a couple of days, when I then return to doing Fedora work, murphy kicks in and I all off a sudden have 5 issues requesting my attention (for some reason issues always come in bumps instead of as a steady trickle), usually resulting in me pushing 4 a 5 bugfix updates in a single day. Thus I would like to voice my concern over the web-form part of this. Preferably this would be handled in the makefile and when typing "make build" for a non-devel branch my $EDITOR would get launched opening a pre-filled template update anouncement, where I can add the necessary bits, and then upon saving this gets automatically entered into the updates system. Basicly every step added to the process is one too much, thus we should try to not add any steps if not absolutely necessary. Don't get me wrong, I'm not against using a proper updates scheme instead of the rolling model of extras (although that always worked well for me). But the whole workflow should be made as smooth as possible, as smooth as baby's buttocks preferably. Regards, Hans From rc040203 at freenet.de Wed May 16 07:45:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 09:45:22 +0200 Subject: Offering packages for co-maintenance or adoption Message-ID: <1179301522.4735.630.camel@mccallum.corsepiu.local> Hi, due to the increased work-load being imposed on maintainers, I not any longer feel able to maintain the following packages in reasonable manners. To be able to concentrate my work-load better on the subset of packages I am most interested in, I am offering the following packages I have been maintaining in Fedora in recent years for co-maintainership or adoption: cvsutils help2man lib3ds perl-Algorithm-Dependency perl-Business-Hours perl-Cache-Simple-TimedExpiry perl-Calendar-Simple perl-capitalization perl-Class-Autouse perl-Class-Inspector perl-Class-ReturnValue perl-DBIx-DBSchema perl-DBIx-SearchBuilder perl-Devel-StackTrace perl-ExtUtils-AutoInstall perl-File-Find-Rule perl-File-Copy-Recursive perl-File-Flat perl-File-NCopy perl-File-Remove perl-File-Slurp perl-Font-AFM perl-gettext perl-HTML-Format perl-HTTP-Server-Simple-Mason perl-Locale-Maketext-Lexicon perl-Mail-GnuPG perl-Module-Refresh perl-Number-Compare perl-Params-Util perl-Params-Validate perl-Pod-Tests perl-prefork perl-Regexp-Common perl-Sort-Versions perl-Test-ClassAPI perl-Test-Inline perl-Test-LongString perl-Test-Taint perl-Text-Glob perl-Text-Quoted perl-Text-Wrapper perl-Tree-Simple perl-Want qhull Please contact me on PM, in case you should be interested. Ralf From nicolas.mailhot at laposte.net Wed May 16 07:58:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 16 May 2007 09:58:04 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070515215414.GJ2828@free.fr> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> Message-ID: <1179302284.27152.4.camel@rousalka.dyndns.org> BTW why can't the update message be the last changelog entry by default? I'd rather require people to write meaningful changelogs than forcing them to pipe the info in a different system. Also changelogs stay and don't require a fancy web infrastructure to be consulted. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dev at nigelj.com Wed May 16 08:27:42 2007 From: dev at nigelj.com (Nigel Jones) Date: Wed, 16 May 2007 20:27:42 +1200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179301522.4735.630.camel@mccallum.corsepiu.local> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> Message-ID: <464AC07E.1060101@nigelj.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Corsepius wrote: > Hi, > > due to the increased work-load being imposed on maintainers, I not any > longer feel able to maintain the following packages in reasonable > manners. > > To be able to concentrate my work-load better on the subset of packages > I am most interested in, I am offering the following packages I have > been maintaining in Fedora in recent years for co-maintainership or > adoption: > > cvsutils I wouldn't mind this one, but I'll pass on the others -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSsB+pldg9bRmG6kRAsSHAJ4oIAvSoiPHS2ni8m/IrFJRweZINwCfUZYp hB+FauqSUf7WxsN0QpDwTxQ= =EaJc -----END PGP SIGNATURE----- From martin.sourada at seznam.cz Wed May 16 08:42:26 2007 From: martin.sourada at seznam.cz (Martin Sourada) Date: Wed, 16 May 2007 10:42:26 +0200 Subject: Policy for backporting patches? Message-ID: <464AC3F2.4070902@seznam.cz> Hello, I'd like to ask whether there is any policy for backporting patches from mainstream when redhat bugzilla is not filled against the problem fixed by the patch? I am maintainer of gxine package and currently wonder whether I should include in my package some patch from gxine trunk [1]... Thanks, Martin References: [1] http://hg.debian.org/hg/xine-lib/gxine?cmd=changeset;node=add6d2a804cb075eb104f1d90eecd15a628708e1;style=gitweb From oliver at linux-kernel.at Wed May 16 08:45:54 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 16 May 2007 10:45:54 +0200 Subject: co maintainance In-Reply-To: <464AC07E.1060101@nigelj.com> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> Message-ID: <464AC4C2.6090507@linux-kernel.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Can we make a wiki page for packages that are free for co maintenance. People who are interested in doing more can go to ONE point and don't need to dig in the mail archives. Maybe add it here: http://fedoraproject.org/wiki/PackageMaintainers/HelpWanted (I would open a new page, if I would be sure there isn't such already.) The way I think of it should be done: 1) Go to the page and see if there are packages that you use regular and are willing to co-maintain. 2) Get in touch with the current packager 3) If the current package monkey (!!! :-) ) is fine with you - take the package from the list and add yourself CC to the owners.list or ask the main maintainer to do this for you if you feel uncomfortable in doing this. 4) Tell the list about this change. +1 from myself :-) - -of -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSsTCxWN5Ge8lKUMRAkmCAJ9gF+28REqv2AAJ55pjVOu75yHXWwCgkh5D +uXZhiHg82ThFWOWYmriTQk= =axPn -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Wed May 16 08:54:44 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 16 May 2007 10:54:44 +0200 Subject: co maintainance In-Reply-To: <464AC4C2.6090507@linux-kernel.at> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <464AC4C2.6090507@linux-kernel.at> Message-ID: <464AC6D4.3020205@hhs.nl> Oliver Falk wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > > Can we make a wiki page for packages that are free for co maintenance. > People who are interested in doing more can go to ONE point and don't > need to dig in the mail archives. > > Maybe add it here: > http://fedoraproject.org/wiki/PackageMaintainers/HelpWanted > > (I would open a new page, if I would be sure there isn't such already.) > > The way I think of it should be done: > 1) Go to the page and see if there are packages that you use regular and > are willing to co-maintain. > 2) Get in touch with the current packager > 3) If the current package monkey (!!! :-) ) is fine with you - take the > package from the list and add yourself CC to the owners.list or ask the > main maintainer to do this for you if you feel uncomfortable in doing this. > > 4) Tell the list about this change. > > +1 from myself :-) > Sounds like a good plan to me +1 Regards, Hans From jspaleta at gmail.com Wed May 16 09:01:59 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 01:01:59 -0800 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179302284.27152.4.camel@rousalka.dyndns.org> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> <1179302284.27152.4.camel@rousalka.dyndns.org> Message-ID: <604aa7910705160201g5a053b1fmc48035aa1e4380ca@mail.gmail.com> On 5/15/07, Nicolas Mailhot wrote: > BTW why can't the update message be the last changelog entry by default? > I'd rather require people to write meaningful changelogs than forcing > them to pipe the info in a different system. +1, i think this is a sane way to minimize perceived burden while still getting useful information into update notification mechanisms. Hell, unless there is some pretty stellar guidance for notification texts that convinces us otherwise, I expect the general practice will be to cut and paste of the changelog text...because its the easiest way to satisfy a notification text requirement. We already sort of have a mechanism to help us cut and pass changlogs for cvs commit messages. If we make the last changelog entry the default update message, which can be overwritten by a more expansive message on a case by case basis, that would suit me just fine. -jef"just need to figure out how to make update notification texts look pretty in the output of a yum cmdline call"spaleta From lemenkov at gmail.com Wed May 16 09:14:13 2007 From: lemenkov at gmail.com (Peter Lemenkov) Date: Wed, 16 May 2007 13:14:13 +0400 Subject: co maintainance In-Reply-To: <464AC4C2.6090507@linux-kernel.at> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <464AC4C2.6090507@linux-kernel.at> Message-ID: 2007/5/16, Oliver Falk : > Can we make a wiki page for packages that are free for co maintenance. > People who are interested in doing more can go to ONE point and don't > need to dig in the mail archives. > > Maybe add it here: > http://fedoraproject.org/wiki/PackageMaintainers/HelpWanted146 Agree. It's a good idea. -- With best regards! From fedora at leemhuis.info Wed May 16 09:20:11 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 May 2007 11:20:11 +0200 Subject: co maintainance In-Reply-To: <464AC4C2.6090507@linux-kernel.at> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <464AC4C2.6090507@linux-kernel.at> Message-ID: <464ACCCB.1040101@leemhuis.info> On 16.05.2007 10:45, Oliver Falk wrote: > > Can we make a wiki page for packages that are free for co maintenance. Just FYI: such pages in my Fedora experience become outdated quite soon often, as people forget to keep it up2date. > People who are interested in doing more can go to ONE point and don't > need to dig in the mail archives. [...] For this specific example it's probably a good idea. But the real solution and "ONE point" is *afaik* to use the Package Database, which afaik should go into production soon. That's btw, the reasons why I didn't encourage co-maintainership more after the proposal was accepted. CU thl -- Fedora-maintainers mailing list Fedora-maintainers at redhat.com https://www.redhat.com/mailman/listinfo/fedora-maintainers From fedora at leemhuis.info Wed May 16 09:23:02 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 16 May 2007 11:23:02 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179302284.27152.4.camel@rousalka.dyndns.org> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> <1179302284.27152.4.camel@rousalka.dyndns.org> Message-ID: <464ACD76.9090705@leemhuis.info> On 16.05.2007 09:58, Nicolas Mailhot wrote: > BTW why can't the update message be the last changelog entry by default? > I'd rather require people to write meaningful changelogs than forcing > them to pipe the info in a different system. > > Also changelogs stay and don't require a fancy web infrastructure to be > consulted. I think something to avoid the "web infrastructure" was considered. But I don't know if it was implemented. /me really wonders if all those people that are discussing here about the drawbacks of the new updates system actually took a look at it CU thl From pmatilai at laiskiainen.org Wed May 16 09:32:49 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 16 May 2007 12:32:49 +0300 (EEST) Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <604aa7910705160201g5a053b1fmc48035aa1e4380ca@mail.gmail.com> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> <1179302284.27152.4.camel@rousalka.dyndns.org> <604aa7910705160201g5a053b1fmc48035aa1e4380ca@mail.gmail.com> Message-ID: On Wed, 16 May 2007, Jeff Spaleta wrote: > On 5/15/07, Nicolas Mailhot wrote: >> BTW why can't the update message be the last changelog entry by default? >> I'd rather require people to write meaningful changelogs than forcing >> them to pipe the info in a different system. > > +1, i think this is a sane way to minimize perceived burden while > still getting useful information into update notification mechanisms. > Hell, unless there is some pretty stellar guidance for notification > texts that convinces us otherwise, I expect the general practice will > be to cut and paste of the changelog text...because its the easiest > way to satisfy a notification text requirement. We already sort of > have a mechanism to help us cut and pass changlogs for cvs commit > messages. > > If we make the last changelog entry the default update message, which > can be overwritten by a more expansive message on a case by case > basis, that would suit me just fine. Sounds like a plan to me. Encouraging good changelog entries is, well, good anyway - look at the quality of FC changelogs before and after the daily rawhide-changes mails. In some cases (eg if the update requires user actions etc) further commentary not really suitable to changelog notation style might be needed but rpm changelog since last published package (or even just the latest entry) would make a nice default. And one that shouldn't be too troublesome for anybody since the message has already been written once... > -jef"just need to figure out how to make update notification texts > look pretty in the output of a yum cmdline call"spaleta The changelog entries are easy, everybody likes rpm --changelog style output, no? :) OTOH for that there already is yum-changelog plugin, update notifications are a little different. - Panu - From oliver at linux-kernel.at Wed May 16 09:40:41 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 16 May 2007 11:40:41 +0200 Subject: co maintainance In-Reply-To: <464ACCCB.1040101@leemhuis.info> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <464AC4C2.6090507@linux-kernel.at> <464ACCCB.1040101@leemhuis.info> Message-ID: <464AD199.8000509@linux-kernel.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/16/2007 11:20 AM, Thorsten Leemhuis wrote: > On 16.05.2007 10:45, Oliver Falk wrote: >> Can we make a wiki page for packages that are free for co maintenance. > > Just FYI: such pages in my Fedora experience become outdated quite soon > often, as people forget to keep it up2date. Sure. Very true. >> People who are interested in doing more can go to ONE point and don't >> need to dig in the mail archives. [...] > > For this specific example it's probably a good idea. But the real > solution and "ONE point" is *afaik* to use the Package Database, which > afaik should go into production soon. Yes, sure, pkgDB. Does it offer a solution for such? If not, will it soon? If not, we should use a wiki as long as we don't have this feature. > That's btw, the reasons why I didn't encourage co-maintainership more > after the proposal was accepted. kk. - -of -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGStGZxWN5Ge8lKUMRAqrgAKC+DmYLtmUbkfIhTWlyAfpfGAekiQCff1VT WMS+IgH47KbSA9kmcFlZ0Kg= =zPTr -----END PGP SIGNATURE----- From a.badger at gmail.com Wed May 16 09:58:03 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 May 2007 02:58:03 -0700 Subject: Updates System In-Reply-To: <464AB4A7.6040209@hhs.nl> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> Message-ID: <1179309483.2746.186.camel@localhost.localdomain> On Wed, 2007-05-16 at 09:37 +0200, Hans de Goede wrote: > Thus I would like to voice my concern over the web-form part of this. > Preferably this would be handled in the makefile and when typing "make build" > for a non-devel branch my $EDITOR would get launched opening a pre-filled > template update anouncement, where I can add the necessary bits, and then upon > saving this gets automatically entered into the updates system. > > Basicly every step added to the process is one too much, thus we should try to > not add any steps if not absolutely necessary. Don't get me wrong, I'm not > against using a proper updates scheme instead of the rolling model of extras > (although that always worked well for me). But the whole workflow should be > made as smooth as possible, as smooth as baby's buttocks preferably. Would a curses-style interface work for you? It looks like it would be pretty easy to write a simple tui in python that first has you fill in the fields similar to the web form, pops open your editor on a temp file to enter/edit some freeform text, and then submits it to the update system using JSON-RPC. Authenticating using the SSL certs might be a bit harder but we could use passwords until that is resolved. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Wed May 16 09:57:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 16 May 2007 11:57:47 +0200 Subject: Updates System In-Reply-To: <1179309483.2746.186.camel@localhost.localdomain> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> Message-ID: <464AD59B.8070907@hhs.nl> Toshio Kuratomi wrote: > On Wed, 2007-05-16 at 09:37 +0200, Hans de Goede wrote: >> Thus I would like to voice my concern over the web-form part of this. >> Preferably this would be handled in the makefile and when typing "make build" >> for a non-devel branch my $EDITOR would get launched opening a pre-filled >> template update anouncement, where I can add the necessary bits, and then upon >> saving this gets automatically entered into the updates system. >> >> Basicly every step added to the process is one too much, thus we should try to >> not add any steps if not absolutely necessary. Don't get me wrong, I'm not >> against using a proper updates scheme instead of the rolling model of extras >> (although that always worked well for me). But the whole workflow should be >> made as smooth as possible, as smooth as baby's buttocks preferably. > > Would a curses-style interface work for you? It looks like it would be > pretty easy to write a simple tui in python that first has you fill in > the fields similar to the web form, pops open your editor on a temp file > to enter/edit some freeform text, and then submits it to the update > system using JSON-RPC. Authenticating using the SSL certs might be a > bit harder but we could use passwords until that is resolved. > That would work, although I would like to see it fill as many of the fields (like package name, version etc) automaticly based on the info already at hand (like the spec file) when running from make build Regards, Hans From tla at rasmil.dk Wed May 16 10:17:33 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Wed, 16 May 2007 12:17:33 +0200 Subject: Updates System In-Reply-To: <464A894A.3050308@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> Message-ID: <464ADA3D.6060006@rasmil.dk> Warren Togami wrote: > However, if you don't wish to participate then you are free to leave. Warren, I think this is a very rude remark. Can't we all calm down a little, and trying to work together an solve the issues, instead of starting a flame war. We all works to make Fedora better and this will not happen if we can't communicate in a respectful way. Tim From sgrubb at redhat.com Wed May 16 10:46:44 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 16 May 2007 06:46:44 -0400 Subject: Policy for backporting patches? In-Reply-To: <464AC3F2.4070902@seznam.cz> References: <464AC3F2.4070902@seznam.cz> Message-ID: <200705160646.44477.sgrubb@redhat.com> On Wednesday 16 May 2007 04:42:26 Martin Sourada wrote: > I'd like to ask whether there is any policy for backporting patches from > mainstream when redhat bugzilla is not filled against the problem fixed by > the patch? My personal opinion, if its a security bug, data corrupter, or something important that doesn't work, I'd say go ahead and patch it. There's nothing to prevent you from filing the bug yourself and then fixing it. A lot of people here in Red Hat do just that if its something that can't be done right away, is important, or needs to be part of an errata. hth, -Steve From paul at city-fan.org Wed May 16 10:58:22 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 16 May 2007 11:58:22 +0100 Subject: Request for comaintainers In-Reply-To: References: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> Message-ID: <464AE3CE.9020006@city-fan.org> KH KH wrote: > PS: About kyum, Someone on the french forum reported that it has > deleted my repository definition: kwizart.repo. I will sanity check > it ... But i'm not a kde user usually... This is probably a manifestation of http://bugzilla.redhat.com/190886 - it's somewhat amazing that this bug is still unfixed upstream if my diagnosis is correct. Paul. From Axel.Thimm at ATrpms.net Wed May 16 11:00:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 May 2007 13:00:51 +0200 Subject: Updates System In-Reply-To: <464AB4A7.6040209@hhs.nl> References: <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> Message-ID: <20070516110051.GD19921@neu.nirvana> Hi, On Wed, May 16, 2007 at 09:37:11AM +0200, Hans de Goede wrote: > Thus I would like to voice my concern over the web-form part of this. > Preferably this would be handled in the makefile and when typing "make > build" for a non-devel branch my $EDITOR would get launched opening a > pre-filled template update anouncement, where I can add the necessary bits, > and then upon saving this gets automatically entered into the updates > system. when I first tested the update system some ages ago I had asked the author whether this could also be done by a cli app, and he was very open to it. So I assume that if this solves 90% of people's concerns then it wouldn't be difficult to have this pure-non-gui cli and just add the announcement text to it. I think one needs to allow for some time for things to iron out and maybe accept that at the beginning there may be some inconveniences. But the true thread on increasing QA is still failing its purpose (announcements are just eye-candy). I'll restate that the only way to do proper QA is to *force* all maintainers to use updates-testing. If not even them test each-others packages, how can we ever expect Joe and Jane to do so? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed May 16 11:14:04 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 03:14:04 -0800 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464ACD76.9090705@leemhuis.info> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> <1179302284.27152.4.camel@rousalka.dyndns.org> <464ACD76.9090705@leemhuis.info> Message-ID: <604aa7910705160414t3517ace8qf11f116efe762b88@mail.gmail.com> On 5/16/07, Thorsten Leemhuis wrote: > /me really wonders if all those people that are discussing here about > the drawbacks of the new updates system actually took a look at it I can't speak for people who have a 100+ packages, and since I've no desire to maintain 100+ packages regardless of the workflow structures, I'm not going to start maintaining 100+ packages just to see if I can substantiate or refute any workflow disruption claims. Regardless of how well any of us eventually learn to conform to the new tool, it is a new tool and it will disrupt workflow. Every policy or tool change disrupts workflow, its just a fact of life. I don't notice the impact of a single change so much because my package maintainership burden is still small enough so that I pretty much assume that package policy/toolsets have changed since the last time I had to do something significant with my packages, so I end up re-reading wikipages every couple of months. Hell a webinterface that walks me through crap is probably going to make it easier for me. The real question is.. can you have a one-size-fits-all interface that caters to low package count,high package count maintainers and everyone in between? I doubt you can. So in an imperfect world, how do we measure how well the new tool decreases or increases the overall workload burden for the entire set of maintainers? What's the mean and the median number of packages per maintainer that we have right now? What is the ideal mean and median number of packagers per maintainer that the tool/policy is designed for? And how do we make sure the infrastructure group gets feedback about the new update system from maintainers in the current/ideal mean/median group? -jef From mclasen at redhat.com Wed May 16 11:53:29 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 16 May 2007 07:53:29 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> <1179302284.27152.4.camel@rousalka.dyndns.org> <604aa7910705160201g5a053b1fmc48035aa1e4380ca@mail.gmail.com> Message-ID: <1179316409.3219.1.camel@dhcp83-33.boston.redhat.com> On Wed, 2007-05-16 at 12:32 +0300, Panu Matilainen wrote: > > Sounds like a plan to me. Encouraging good changelog entries is, well, > good anyway - look at the quality of FC changelogs before and after the > daily rawhide-changes mails. In some cases (eg if the update requires user > actions etc) further commentary not really suitable to changelog notation > style might be needed but rpm changelog since last published package (or > even just the latest entry) would make a nice default. And one that > shouldn't be too troublesome for anybody since the message has already > been written once... > The problem with reusing changelog entries for update notification is that they are written for an entirely different audience: changelogs -> developers announcements -> users From nicolas.mailhot at laposte.net Wed May 16 12:04:13 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 16 May 2007 14:04:13 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179316409.3219.1.camel@dhcp83-33.boston.redhat.com> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <464A2750.7040805@fedoraproject.org> <20070515213642.GG2828@free.fr> <200705151748.20520.jkeating@redhat.com> <20070515215414.GJ2828@free.fr> <1179302284.27152.4.camel@rousalka.dyndns.org> <604aa7910705160201g5a053b1fmc48035aa1e4380ca@mail.gmail.com> <1179316409.3219.1.camel@dhcp83-33.boston.redhat.com> Message-ID: <1179317053.3459.5.camel@rousalka.dyndns.org> Le mercredi 16 mai 2007 ? 07:53 -0400, Matthias Clasen a ?crit : > The problem with reusing changelog entries for update notification is > that they are written for an entirely different audience: > > changelogs -> developers > announcements -> users 1. they shouldn't 2. don't dream, you won't get better update texts anyway 3. for the vast majority of non-english-speaking Fedora users there is zip difference between a changelog entry and whatever english text an exceptionally motivated packager would write on a good day -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Wed May 16 12:22:30 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 14:22:30 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <464AC07E.1060101@nigelj.com> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> Message-ID: <1179318150.4735.642.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 20:27 +1200, Nigel Jones wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ralf Corsepius wrote: > > Hi, > > > > due to the increased work-load being imposed on maintainers, I not any > > longer feel able to maintain the following packages in reasonable > > manners. > > > > To be able to concentrate my work-load better on the subset of packages > > I am most interested in, I am offering the following packages I have > > been maintaining in Fedora in recent years for co-maintainership or > > adoption: > > > > cvsutils > I wouldn't mind this one, but I'll pass on the others Fine. I would have added you as co-maintainer of cvsutils in owners.list but apparently the procedures outlined on http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages?action=show&redirect=Extras%2FOrphanedPackages also do not apply anymore: $ cvs commit -m 'Add Nigel Jones as comaintainer of cvsutils.' owners.list Enter passphrase for key '/users/corsepiu/.ssh/id_dsa': **** Access allowed: corsepiu is in ACL for /cvs/pkgs/owners. Checking in owners.list; /cvs/extras/owners/owners.list,v <-- owners.list new revision: 1.2882; previous revision: 1.2881 cvs [commit aborted]: could not open lock file `/cvs/extras/owners/,owners.list,': Permission denied Which form did I miss to fill out, now? Ralf From jwboyer at jdub.homelinux.org Wed May 16 12:27:51 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 07:27:51 -0500 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179318150.4735.642.camel@mccallum.corsepiu.local> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> Message-ID: <1179318471.13214.11.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 14:22 +0200, Ralf Corsepius wrote: > On Wed, 2007-05-16 at 20:27 +1200, Nigel Jones wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Ralf Corsepius wrote: > > > Hi, > > > > > > due to the increased work-load being imposed on maintainers, I not any > > > longer feel able to maintain the following packages in reasonable > > > manners. > > > > > > To be able to concentrate my work-load better on the subset of packages > > > I am most interested in, I am offering the following packages I have > > > been maintaining in Fedora in recent years for co-maintainership or > > > adoption: > > > > > > cvsutils > > I wouldn't mind this one, but I'll pass on the others > > Fine. I would have added you as co-maintainer of cvsutils in owners.list > but apparently the procedures outlined on > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages?action=show&redirect=Extras%2FOrphanedPackages > also do not apply anymore: > > $ cvs commit -m 'Add Nigel Jones as comaintainer of cvsutils.' owners.list > Enter passphrase for key '/users/corsepiu/.ssh/id_dsa': > **** Access allowed: corsepiu is in ACL for /cvs/pkgs/owners. > Checking in owners.list; > /cvs/extras/owners/owners.list,v <-- owners.list > new revision: 1.2882; previous revision: 1.2881 > cvs [commit aborted]: could not open lock file > `/cvs/extras/owners/,owners.list,': Permission denied > > Which form did I miss to fill out, now? http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure josh From jwboyer at jdub.homelinux.org Wed May 16 12:44:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 07:44:48 -0500 Subject: 5/16/2007 Broken upgrade paths in F7 Message-ID: <1179319488.13214.21.camel@zod.rchland.ibm.com> Hi All, Below you'll find the broken upgrade paths report against the latest rawhide. Please note that there are a few packages on this list which have pending rel-eng requests. josh Report for 5/16/2007 asymptote: FE6 > F7 (0:1.28-1.fc6 > 0:1.26-1.fc7) asymptote-1.28-1.fc7 dist-fc7 jpo bitlbee: FE6 > F7 (0:1.0.3-6.fc6 > 0:1.0.3-5.fc7) bitlbee-1.0.3-6.fc7 dist-fc7 robert cacti: FE6 > F7 (0:0.8.6j-1.fc6 > 0:0.8.6i-5.fc7) cacti-0.8.6j-1.fc7 dist-fc7 mmcgrath duplicity: FE6 > F7 (0:0.4.2-7.fc6 > 0:0.4.2-6.fc7) duplicity-0.4.2-7.fc7 dist-fc7 robert eggdrop: FE6 > F7 (0:1.6.18-8.fc6 > 0:1.6.18-7.fc7) eggdrop-1.6.18-8.fc7 dist-fc7 robert em8300-kmod: FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop fortune-firefly: FE6 > F7 (0:2.1.2-2.fc6 > 0:2.1.1-2.fc6) fuse: FE6 > F7 (0:2.6.5-1.fc6 > 0:2.6.3-2.fc7) fuse-2.6.5-1.fc7 dist-fc7 peter gallery2: FE6 > F7 (0:2.2-0.4.svn20070506.fc6 > 0:2.1-0.24.svn20060817.fc6) gallery2-2.2-0.5.svn20070506.fc7 dist-fc7 jwb gtk+extra: FE6 > F7 (0:2.1.1-4.fc6 > 0:2.1.1-3.fc6) gtk+extra-2.1.1-4.fc7 dist-fc7 dionysos libopm: FE6 > F7 (0:0.1-4.20050731cvs.fc6 > 0:0.1-3.20050731cvs.fc7) libopm-0.1-4.20050731cvs.fc7 dist-fc7 robert librfid: FE6 > F7 (0:0.1.0-3.1996svn.fc6 > 0:0.1.0-2.fc7) librfid-0.1.0-3.1996svn.fc7 dist-fc7 kushal librsync: FE6 > F7 (0:0.9.7-10.fc6 > 0:0.9.7-9.fc7) librsync-0.9.7-10.fc7 dist-fc7 robert libxml2: FC6-updates > F7 (0:2.6.28-1.fc6 > 0:2.6.28-1) libxml2-2.6.28-1 dist-fc7 jkeating libxml2-2.6.28-1 f7-test4 jkeating m4: FC6-updates > F7 (0:1.4.8-2 > 0:1.4.8-1) m4-1.4.8-2.fc7 dist-fc7 jkeating mimedefang: FE6 > F7 (0:2.62-2.fc6 > 0:2.62-1.fc7) mimedefang-2.62-2.fc7 dist-fc7 robert moin: FE6 > F7 (0:1.5.7-2.fc6 > 0:1.5.7-1.fc7) moin-1.5.7-2.fc7 dist-fc7 thias perl-File-Copy-Recursive: FE6 > F7 (0:0.33-1.fc6 > 0:0.31-2.fc7) perl-File-Copy-Recursive-0.33-2.fc7 dist-fc7 corsepiu perl-Module-Refresh: FE6 > F7 (0:0.13-1.fc6 > 0:0.11-1.fc7) perl-Module-Refresh-0.13-1.fc7 dist-fc7 corsepiu perl-Module-ScanDeps: FE6 > F7 (0:0.74-1.fc6 > 0:0.73-1.fc7) perl-Module-ScanDeps-0.74-1.fc7 dist-fc7 jpo perl-Net-LibIDN: FE6 > F7 (0:0.09-3.fc6 > 0:0.09-2.fc7) perl-Net-LibIDN-0.09-3.fc7 dist-fc7 robert perl-Pod-Strip: FE6 > F7 (0:1.02-2.fc6 > 0:1.02-1.fc7) perl-Pod-Strip-1.02-2.fc7 dist-fc7 jpo perl-Test-Warn: FE6 > F7 (0:0.10-1.fc6 > 0:0.09-1.fc7) perl-Test-Warn-0.10-1.fc7 dist-fc7 jpo perl-Text-Glob: FE6 > F7 (0:0.08-1.fc6 > 0:0.07-2.fc6) perl-Text-Glob-0.08-1.fc7 dist-fc7 corsepiu perl-Want: FE6 > F7 (0:0.14-1.fc6 > 0:0.12-2.fc7) perl-Want-0.14-1.fc7 dist-fc7 corsepiu php-idn: FE6 > F7 (0:1.2-2.fc6 > 0:1.2-1.fc7) php-idn-1.2-2.fc7 dist-fc7 robert quodlibet: FE6 > F7 (0:1.0-1.fc6 > 0:0.24-7.fc7) quodlibet-1.0-1.fc7 dist-fc7 jcollie rosegarden4: FE6 > F7 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) rrdtool: FE6 > F7 (0:1.2.23-3.fc6 > 0:1.2.19-2.fc7) rrdtool-1.2.23-3.fc7 dist-fc7 jwilson shorewall: FE6 > F7 (0:3.4.3-1.fc6 > 0:3.4.2-1.fc7) shorewall-3.4.3-1.fc7 dist-fc7 robmv smb4k: FE6 > F7 (0:0.8.3-1.fc6 > 0:0.8.2-1.fc7) smb4k-0.8.3-1.fc7 dist-fc7 mgarski sonata: FE6 > F7 (0:1.1-1.fc6 > 0:1.0.1-3.fc7) sonata-1.1-1.fc7 dist-fc7 ecik tcpick: FE6 > F7 (0:0.2.1-12.fc6 > 0:0.2.1-11.fc7) tcpick-0.2.1-12.fc7 dist-fc7 robert transmission: FE6 > F7 (0:0.72-1.fc6 > 0:0.71-1.fc7) transmission-0.72-1.fc7 dist-fc7 denis wavpack: FE6 > F7 (0:4.41-1.fc6 > 0:4.40-1.1.fc7) wavpack-4.41-1.fc7 dist-fc7 peter wine: FE6 > F7 (0:0.9.36-2.fc6 > 0:0.9.36-1.fc7) wine-0.9.36-2.fc7 dist-fc7 awjb From jwboyer at jdub.homelinux.org Wed May 16 13:03:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 08:03:58 -0500 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <1179319488.13214.21.camel@zod.rchland.ibm.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> Message-ID: <1179320638.13214.31.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 07:44 -0500, Josh Boyer wrote: > > em8300-kmod: > FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) > em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop rel-eng knows about this one already. Ville is waiting on the final kernel version to be decided so he can tag the appropriate module. > > gallery2: > FE6 > F7 (0:2.2-0.4.svn20070506.fc6 > 0:2.1-0.24.svn20060817.fc6) > gallery2-2.2-0.5.svn20070506.fc7 dist-fc7 jwb This one is being worked through the rel-eng process. > libxml2: > FC6-updates > F7 (0:2.6.28-1.fc6 > 0:2.6.28-1) > libxml2-2.6.28-1 dist-fc7 jkeating > libxml2-2.6.28-1 f7-test4 jkeating Looks like the disttag got dropped or something? > perl-File-Copy-Recursive: > FE6 > F7 (0:0.33-1.fc6 > 0:0.31-2.fc7) > perl-File-Copy-Recursive-0.33-2.fc7 dist-fc7 corsepiu > > perl-Module-Refresh: > FE6 > F7 (0:0.13-1.fc6 > 0:0.11-1.fc7) > perl-Module-Refresh-0.13-1.fc7 dist-fc7 corsepiu > > perl-Text-Glob: > FE6 > F7 (0:0.08-1.fc6 > 0:0.07-2.fc6) > perl-Text-Glob-0.08-1.fc7 dist-fc7 corsepiu > > perl-Want: > FE6 > F7 (0:0.14-1.fc6 > 0:0.12-2.fc7) > perl-Want-0.14-1.fc7 dist-fc7 corsepiu > These will be fixed. > wine: > FE6 > F7 (0:0.9.36-2.fc6 > 0:0.9.36-1.fc7) > wine-0.9.36-2.fc7 dist-fc7 awjb This one has a pending request to rel-eng. josh From jkeating at redhat.com Wed May 16 13:11:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 09:11:02 -0400 Subject: Updates System In-Reply-To: <1179299948.4735.622.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> Message-ID: <200705160911.02993.jkeating@redhat.com> On Wednesday 16 May 2007 03:19:08 Ralf Corsepius wrote: > Update 40 packages at once and you'll probably notice why I consider > this to be a crack ridden work-flow. 2 steps more per package and one > form per package demonstrates the flaws of this workflow. Given that the tool allows you to release multiple packages with the same announcement / reasons / bugs / etc it is quite easy to prepare a stack of packages for update, say a flaw in a library is discovered, you have to build a new version of library, and a bunch of downstream packages against said library, you can release the entire stack under a single web form, and now all your updates have context, and it can even autoupdate a bug once it is pushed to the world. > 0) maintainer tests package's ?functionality. > > > 1) Maintainer checks changes into CVS branch. > > 2) Maintainer builds. > > 3) Maintainer tests that build. > > 4) Maintainer fills out the form with the N-V-R, optional security > > (yes/no), optional Bug numbers fixed, and some fills in some details of > > what the update is about, then chooses updates or updates-testing. > > 5) Submit, where security and/or rel-eng team pushes it through. > > Now where in this scheme is Will Woods? I don't see him testing > anything. All I see is more bureaucracy and more manual steps than > before. Perhaps this is where we're not communicating clearly enough. Will isn't going to be doing (all) the testing himself. However Will is going to be driving a QA team and anybody else who is interested to make use of the public updates-testing repo. The testing will be the wider audience of those that use updates-testing and who may have configurations or situations beyond what you as the maintainer could test yourself before releasing the updates. It gives you a chance to land the update on more people's machines for wider testing before just lobbing it over the wall at our general user base. And if the update isn't quite right, well it was in updates-testing so no harm, no foul. If the update wasn't quite right and you pushed it into -final updates and everybody's machine now you've just given not only yourself a bad name as a maintainer, but you've given Fedora a bad name as a distro too. (yes yes, we all know you consider Fedora to be a horrible distro already, but many of us don't.) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed May 16 13:16:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 09:16:38 -0400 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179318150.4735.642.camel@mccallum.corsepiu.local> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> Message-ID: <200705160916.39263.jkeating@redhat.com> On Wednesday 16 May 2007 08:22:30 Ralf Corsepius wrote: > Fine. I would have added you as co-maintainer of cvsutils in owners.list > but apparently the procedures outlined on > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages?action=sh >ow&redirect=Extras%2FOrphanedPackages also do not apply anymore: > > $ cvs commit -m 'Add Nigel Jones as comaintainer of cvsutils.' owners.list > Enter passphrase for key '/users/corsepiu/.ssh/id_dsa': > **** Access allowed: corsepiu is in ACL for /cvs/pkgs/owners. > Checking in owners.list; > /cvs/extras/owners/owners.list,v ?<-- ?owners.list > new revision: 1.2882; previous revision: 1.2881 > cvs [commit aborted]: could not open lock file > `/cvs/extras/owners/,owners.list,': Permission denied > > Which form did I miss to fill out, now? Thank you for finding an out of date instruction. I have now fixed this page to reference the right procedure, http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed May 16 13:17:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 15:17:22 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179318471.13214.11.camel@zod.rchland.ibm.com> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> <1179318471.13214.11.camel@zod.rchland.ibm.com> Message-ID: <1179321442.4735.685.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 07:27 -0500, Josh Boyer wrote: > On Wed, 2007-05-16 at 14:22 +0200, Ralf Corsepius wrote: > > On Wed, 2007-05-16 at 20:27 +1200, Nigel Jones wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Ralf Corsepius wrote: > > > > Hi, > > > > > > > > due to the increased work-load being imposed on maintainers, I not any > > > > longer feel able to maintain the following packages in reasonable > > > > manners. > > > > > > > > To be able to concentrate my work-load better on the subset of packages > > > > I am most interested in, I am offering the following packages I have > > > > been maintaining in Fedora in recent years for co-maintainership or > > > > adoption: > > > > > > > > cvsutils > > > I wouldn't mind this one, but I'll pass on the others > > > > Fine. I would have added you as co-maintainer of cvsutils in owners.list > > but apparently the procedures outlined on > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages?action=show&redirect=Extras%2FOrphanedPackages > > also do not apply anymore: > > > > $ cvs commit -m 'Add Nigel Jones as comaintainer of cvsutils.' owners.list > > Enter passphrase for key '/users/corsepiu/.ssh/id_dsa': > > **** Access allowed: corsepiu is in ACL for /cvs/pkgs/owners. > > Checking in owners.list; > > /cvs/extras/owners/owners.list,v <-- owners.list > > new revision: 1.2882; previous revision: 1.2881 > > cvs [commit aborted]: could not open lock file > > `/cvs/extras/owners/,owners.list,': Permission denied > > > > Which form did I miss to fill out, now? ... yet some more missing documentation ... > http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure Thanks for link, but I regret having to say so, the procedure outlined there is such kind of time-consuming that it is hardly applicable for ca. 30 packages. Ralf From jkeating at redhat.com Wed May 16 13:20:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 09:20:42 -0400 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179321442.4735.685.camel@mccallum.corsepiu.local> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <1179318471.13214.11.camel@zod.rchland.ibm.com> <1179321442.4735.685.camel@mccallum.corsepiu.local> Message-ID: <200705160920.42810.jkeating@redhat.com> On Wednesday 16 May 2007 09:17:22 Ralf Corsepius wrote: > > http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > Thanks for link, but I regret having to say so, the procedure outlined > there is such kind of time-consuming that it is hardly applicable for > ca. 30 packages. This is the current procedure due to having owners.list drive the ACLs within our packaging SCM. The eventual gameplan here is to have packageDB manage this and allow users to simply make requests within the PackageDB and maintainers approve/disapprove said requests. This is a temporary pain point. Please bear with us as we grow as a distribution and as a community. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed May 16 13:20:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 08:20:23 -0500 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179321442.4735.685.camel@mccallum.corsepiu.local> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> <1179318471.13214.11.camel@zod.rchland.ibm.com> <1179321442.4735.685.camel@mccallum.corsepiu.local> Message-ID: <1179321623.13214.44.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 15:17 +0200, Ralf Corsepius wrote: > On Wed, 2007-05-16 at 07:27 -0500, Josh Boyer wrote: > > On Wed, 2007-05-16 at 14:22 +0200, Ralf Corsepius wrote: > > > On Wed, 2007-05-16 at 20:27 +1200, Nigel Jones wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > Ralf Corsepius wrote: > > > > > Hi, > > > > > > > > > > due to the increased work-load being imposed on maintainers, I not any > > > > > longer feel able to maintain the following packages in reasonable > > > > > manners. > > > > > > > > > > To be able to concentrate my work-load better on the subset of packages > > > > > I am most interested in, I am offering the following packages I have > > > > > been maintaining in Fedora in recent years for co-maintainership or > > > > > adoption: > > > > > > > > > > cvsutils > > > > I wouldn't mind this one, but I'll pass on the others > > > > > > Fine. I would have added you as co-maintainer of cvsutils in owners.list > > > but apparently the procedures outlined on > > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages?action=show&redirect=Extras%2FOrphanedPackages > > > also do not apply anymore: > > > > > > $ cvs commit -m 'Add Nigel Jones as comaintainer of cvsutils.' owners.list > > > Enter passphrase for key '/users/corsepiu/.ssh/id_dsa': > > > **** Access allowed: corsepiu is in ACL for /cvs/pkgs/owners. > > > Checking in owners.list; > > > /cvs/extras/owners/owners.list,v <-- owners.list > > > new revision: 1.2882; previous revision: 1.2881 > > > cvs [commit aborted]: could not open lock file > > > `/cvs/extras/owners/,owners.list,': Permission denied > > > > > > Which form did I miss to fill out, now? > ... yet some more missing documentation ... > > > http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > Thanks for link, but I regret having to say so, the procedure outlined > there is such kind of time-consuming that it is hardly applicable for > ca. 30 packages. For something of that scale, we can probably work out something. E.g. opening a new bug with a batch of requests, etc. When you have several to modify, send an email to cvsadmin-members at fedoraproject.org and we'll see what we can do. josh From jwboyer at jdub.homelinux.org Wed May 16 13:22:49 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 08:22:49 -0500 Subject: Updates System In-Reply-To: <200705160911.02993.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <200705160911.02993.jkeating@redhat.com> Message-ID: <1179321769.13214.47.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 09:11 -0400, Jesse Keating wrote: > (yes yes, we all know you consider Fedora to be a horrible distro already, > but many of us don't.) To be fair, I think Ralf has issues with the policies and procedures of Fedora. Not the distro, as in "collection of packages" itself. josh From jima at beer.tclug.org Wed May 16 13:25:09 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 16 May 2007 08:25:09 -0500 (CDT) Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179287703.4735.589.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> Message-ID: On Wed, 16 May 2007, Ralf Corsepius wrote: > On Tue, 2007-05-15 at 13:25 -0400, Will Woods wrote: >> How does that lock out *anything*? What are you even talking about? > * E.g. about API, SONAME changes, compat-packages etc. If you're going > to freeze APIs, SONAMEs etc. you're locking out packages. > * By forcing maintainers to fill out forms or similar steps, you are > imposing additional load on maintainers. I for one don't have any time > available to waste on this kind of kid stuff. As a consequence you'll be > facing me not upgrading packages. You don't have time to write a short snippet on why you feel a package update is necessary, but you have time to argue for days about how this is a bad idea. I think you need to go to a time management class. If only you had the time... Jima From pertusus at free.fr Wed May 16 13:54:26 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 15:54:26 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> Message-ID: <20070516135426.GC3228@free.fr> On Wed, May 16, 2007 at 08:25:09AM -0500, Jima wrote: > > You don't have time to write a short snippet on why you feel a package > update is necessary, but you have time to argue for days about how this is > a bad idea. > I think you need to go to a time management class. If only you had the > time... Please, it is not necessarily something we like to do, arguing about processes, in my opinion is time consuming and not very productive. However it is an important part of our work as community members. Ralf is certainly very busy, he maintains a lot of packages and has invaluable knowledge, so please refrain from telling him how he should spend his time. -- Pat From pertusus at free.fr Wed May 16 13:56:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 15:56:07 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179286874.4180.3.camel@localhost.localdomain> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <20070515170227.GH2815@free.fr> <1179250504.1459.46.camel@metroid.rdu.redhat.com> <20070515204800.GD2828@free.fr> <1179286874.4180.3.camel@localhost.localdomain> Message-ID: <20070516135607.GD3228@free.fr> On Tue, May 15, 2007 at 11:41:14PM -0400, Matthias Clasen wrote: > On Tue, 2007-05-15 at 22:48 +0200, Patrice Dumas wrote: > > I think it is a bit silly to claim some "maintainer privilege" for this > (which is actually a very important part of ensuring a good update > experience for users), when we are at the same time force packagers > to justify every comma they may have misplaced in a spec file during > package reviews (which has very little bearing on the user experience). In general what is highlighten during package submission are best practices, and things that don't get in the maintainer way for each updates. It is very different. -- Pat From rc040203 at freenet.de Wed May 16 14:06:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 16:06:08 +0200 Subject: Updates System In-Reply-To: <200705160911.02993.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <200705160911.02993.jkeating@redhat.com> Message-ID: <1179324368.4735.718.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 09:11 -0400, Jesse Keating wrote: > On Wednesday 16 May 2007 03:19:08 Ralf Corsepius wrote: > > Update 40 packages at once and you'll probably notice why I consider > > this to be a crack ridden work-flow. 2 steps more per package and one > > form per package demonstrates the flaws of this workflow. > > Given that the tool allows you to release multiple packages with the same > announcement / reasons / bugs / etc it is quite easy to prepare a stack of > packages for update, say a flaw in a library is discovered, you have to build > a new version of library, and a bunch of downstream packages against said > library, you can release the entire stack under a single web form, and now > all your updates have context, and it can even autoupdate a bug once it is > pushed to the world. Where is this documented? URL? > > 0) maintainer tests package's functionality. > > > > > 1) Maintainer checks changes into CVS branch. > > > 2) Maintainer builds. > > > 3) Maintainer tests that build. > > > 4) Maintainer fills out the form with the N-V-R, optional security > > > (yes/no), optional Bug numbers fixed, and some fills in some details of > > > what the update is about, then chooses updates or updates-testing. > > > 5) Submit, where security and/or rel-eng team pushes it through. > > > > Now where in this scheme is Will Woods? I don't see him testing > > anything. All I see is more bureaucracy and more manual steps than > > before. > > Perhaps this is where we're not communicating clearly enough. Will isn't > going to be doing (all) the testing himself. However Will is going to be > driving a QA team and anybody else who is interested to make use of the > public updates-testing repo. I still fail to understand what he does and how a community package is supposed to profit from this. What does he do, what a "package consistency checker" can't and what can't be achieved by having a repo containing packages? > The testing will be the wider audience of those > that use updates-testing and who may have configurations or situations beyond > what you as the maintainer could test yourself before releasing the updates. > It gives you a chance to land the update on more people's machines for wider > testing before just lobbing it over the wall at our general user base. And > if the update isn't quite right, well it was in updates-testing so no harm, > no foul. If the update wasn't quite right and you pushed it into -final > updates and everybody's machine now you've just given not only yourself a bad > name as a maintainer, but you've given Fedora a bad name as a distro too. > (yes yes, we all know you consider Fedora to be a horrible distro already, > but many of us don't.) This impression is wrong. I don't consider Fedora to be a horrible distro - at least technically, otherwise I wasn't using it? Truth is - and this likely won't taste you - I consider * its infrastructure having been introduced with the merger to be a series of horrible mistakes, the new workflow to be largely bureaucratic, and the shape this all currently is in to be a shame. * this all to be a symptom of Fedora leadership to have failed at a large extend. * RH to have betrayed opensource and measuring "openness of SW" by selfish double standards, by having allowed "non-modifiable" firmware in Fedora while banning other "non-OSI-compliant" SW. Truth also is: So far, I feel the negative effects of the merger to outweigh the positive effects. More pragmatically: Over all these years Fedora exists, it has ever been a major problem to me to maintain ca. 45 packages over 3-5 versions/distros in FE. Now it is - In short: a regression. Ralf From jkeating at redhat.com Wed May 16 14:14:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 10:14:32 -0400 Subject: Updates System In-Reply-To: <1179324368.4735.718.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <200705160911.02993.jkeating@redhat.com> <1179324368.4735.718.camel@mccallum.corsepiu.local> Message-ID: <200705161014.33161.jkeating@redhat.com> On Wednesday 16 May 2007 10:06:08 Ralf Corsepius wrote: > Where is this documented? URL? I don't know if it's documented yet. I know that the previous incarnation of this that is used internally for Core updates allows for this, and that the new incarnation of it would too. > > > 0) maintainer tests package's ?functionality. > > > > > > > 1) Maintainer checks changes into CVS branch. > > > > 2) Maintainer builds. > > > > 3) Maintainer tests that build. > > > > 4) Maintainer fills out the form with the N-V-R, optional security > > > > (yes/no), optional Bug numbers fixed, and some fills in some details > > > > of what the update is about, then chooses updates or updates-testing. > > > > 5) Submit, where security and/or rel-eng team pushes it through. > > > > > > Now where in this scheme is Will Woods? I don't see him testing > > > anything. All I see is more bureaucracy and more manual steps than > > > before. > > > > Perhaps this is where we're not communicating clearly enough. ?Will isn't > > going to be doing (all) the testing himself. ?However Will is going to be > > driving a QA team and anybody else who is interested to make use of the > > public updates-testing repo. > > I still fail to understand what he does and how a community package is > supposed to profit from this. > > What does he do, what a "package consistency checker" can't and what > can't be achieved by having a repo containing packages? http://fedoraproject.org/wiki/WillWoods -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed May 16 14:15:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 16:15:30 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <200705160916.39263.jkeating@redhat.com> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> <200705160916.39263.jkeating@redhat.com> Message-ID: <20070516141530.GE3228@free.fr> On Wed, May 16, 2007 at 09:16:38AM -0400, Jesse Keating wrote: > Thank you for finding an out of date instruction. I have now fixed this page > to reference the right procedure, > http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure I reported it earlier (on 10 may), but only Michael replied that he didn't modified the pages anymore... Anyway the modification doesn't really clarify things since there is nothing about orphaning on CVSAdminProcedure. And which co-maintainer is it about? I think the change should be in the next section, about claiming ownership. -- Pat From jkeating at redhat.com Wed May 16 14:35:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 10:35:54 -0400 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <20070516141530.GE3228@free.fr> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <200705160916.39263.jkeating@redhat.com> <20070516141530.GE3228@free.fr> Message-ID: <200705161035.54820.jkeating@redhat.com> On Wednesday 16 May 2007 10:15:30 Patrice Dumas wrote: > I reported it earlier (on 10 may), but only Michael replied that he > didn't modified the pages anymore... > > Anyway the modification doesn't really clarify things since there is > nothing about orphaning on CVSAdminProcedure. And which co-maintainer > is it about? I think the change should be in the next section, about > claiming ownership. So make the change. It's a wiki. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed May 16 14:37:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 16:37:39 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <200705161035.54820.jkeating@redhat.com> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <200705160916.39263.jkeating@redhat.com> <20070516141530.GE3228@free.fr> <200705161035.54820.jkeating@redhat.com> Message-ID: <20070516143739.GF3228@free.fr> On Wed, May 16, 2007 at 10:35:54AM -0400, Jesse Keating wrote: > > So make the change. It's a wiki. How could I make the change I don't know what is to be written! I don't know what is the procedure to orphan in the merged world, that's what I asked in my mail. I don't follow the infrastructure stuff (I follow it only as a maintainer). -- Pat From bugs.michael at gmx.net Wed May 16 14:52:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 16 May 2007 16:52:50 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179318150.4735.642.camel@mccallum.corsepiu.local> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> Message-ID: <20070516165250.3832c90e.bugs.michael@gmx.net> On Wed, 16 May 2007 14:22:30 +0200, Ralf Corsepius wrote: > I would have added you as co-maintainer of cvsutils in owners.list > but apparently the procedures outlined on > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages?action=show&redirect=Extras%2FOrphanedPackages > also do not apply anymore: 1) There has never been a separate Wiki page that covers owners.list. 2) That you find the OrphanedPackages page during your search for documentation on how to add package co-maintainers or new maintainers adds confirmation for 1). 3) The Fedora Extras community used to be able to control their packages, including package ownership, co-ownership, and orphans. We used to be able to handle all that ourselves. But recently, a cage has been set up for the monkeys. Look in the list archives (February 20th), the message with the subject "Orphanizing the OrphanedPackages Wiki page") is the announcement that the page is unmaintained. From bugs.michael at gmx.net Wed May 16 14:59:15 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 16 May 2007 16:59:15 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <20070516141530.GE3228@free.fr> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> <200705160916.39263.jkeating@redhat.com> <20070516141530.GE3228@free.fr> Message-ID: <20070516165915.12f19ac5.bugs.michael@gmx.net> On Wed, 16 May 2007 16:15:30 +0200, Patrice Dumas wrote: > On Wed, May 16, 2007 at 09:16:38AM -0400, Jesse Keating wrote: > > Thank you for finding an out of date instruction. I have now fixed this page > > to reference the right procedure, > > http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > I reported it earlier (on 10 may), but only Michael replied that he > didn't modified the pages anymore... Inaccurate. I've just corrected Jesse's strange edit, btw. The page should be dropped, though, provided that the package db can replace it. What I've announced in February is that I've discontinued *all* background-work around handling orphans in Fedora Extras. Watching the Wiki changes and keeping the page maintained was just one fraction. From rc040203 at freenet.de Wed May 16 15:01:03 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 17:01:03 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> Message-ID: <1179327663.4735.735.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 08:25 -0500, Jima wrote: > On Wed, 16 May 2007, Ralf Corsepius wrote: > > On Tue, 2007-05-15 at 13:25 -0400, Will Woods wrote: > >> How does that lock out *anything*? What are you even talking about? > > * E.g. about API, SONAME changes, compat-packages etc. If you're going > > to freeze APIs, SONAMEs etc. you're locking out packages. > > * By forcing maintainers to fill out forms or similar steps, you are > > imposing additional load on maintainers. I for one don't have any time > > available to waste on this kind of kid stuff. As a consequence you'll be > > facing me not upgrading packages. > > You don't have time to write a short snippet on why you feel a package > update is necessary, but you have time to argue for days about how this is > a bad idea. ... better fight a war once than having to cope with evil mal practices for ever. ... imagine to rebuild several dozens of packages depending on a base-package for different versions of Fedora because something in the base-package has changed. e.g. reflecting the ongoing perl-split to dozens of perl-modules and wanting to keep the diffs minimal. Depending on how things are supposed to work out ... this will be very tedious. Ralf From jkeating at redhat.com Wed May 16 15:29:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 11:29:20 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179327663.4735.735.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <1179327663.4735.735.camel@mccallum.corsepiu.local> Message-ID: <200705161129.20554.jkeating@redhat.com> On Wednesday 16 May 2007 11:01:03 Ralf Corsepius wrote: > ... imagine to rebuild several dozens of packages depending on a > base-package for different versions of Fedora because something in the > base-package has changed. > > e.g. reflecting the ongoing perl-split to dozens of perl-modules and > wanting to keep the diffs minimal. Depending on how things are supposed > to work out ... this will be very tedious. Which could all be issued as _one_ update. So one snippit to write for the entire set. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed May 16 15:30:29 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 11:30:29 -0400 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <20070516165250.3832c90e.bugs.michael@gmx.net> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <1179318150.4735.642.camel@mccallum.corsepiu.local> <20070516165250.3832c90e.bugs.michael@gmx.net> Message-ID: <200705161130.30202.jkeating@redhat.com> On Wednesday 16 May 2007 10:52:50 Michael Schwendt wrote: > 3) The Fedora Extras community used to be able to control their packages, > including package ownership, co-ownership, and orphans. We used to be > able to handle all that ourselves. But recently, a cage has been set up > for the monkeys. Look in the list archives (February 20th), the message > with the subject "Orphanizing the OrphanedPackages Wiki page") is the > announcement that the page is unmaintained. It's only a temporary "cage" until packageDB is up and running, then maintainers can handle it themselves again. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Wed May 16 15:31:39 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 16 May 2007 10:31:39 -0500 (CDT) Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179327663.4735.735.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <1179327663.4735.735.camel@mccallum.corsepiu.local> Message-ID: On Wed, 16 May 2007, Ralf Corsepius wrote: > On Wed, 2007-05-16 at 08:25 -0500, Jima wrote: >> You don't have time to write a short snippet on why you feel a package >> update is necessary, but you have time to argue for days about how this is >> a bad idea. > ... better fight a war once than having to cope with evil mal practices > for ever. We all have our rationalizations. > ... imagine to rebuild several dozens of packages depending on a > base-package for different versions of Fedora because something in the > base-package has changed. Bzzt, wrong. Jesse Keating already addressed this scenario: --- snip --- Given that the tool allows you to release multiple packages with the same announcement / reasons / bugs / etc it is quite easy to prepare a stack of packages for update, say a flaw in a library is discovered, you have to build a new version of library, and a bunch of downstream packages against said library, you can release the entire stack under a single web form, and now all your updates have context, and it can even autoupdate a bug once it is pushed to the world. --- snip --- Want to try another argument? Jima From cweyl at alumni.drew.edu Wed May 16 16:02:28 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 16 May 2007 09:02:28 -0700 Subject: Updates System In-Reply-To: <1179309483.2746.186.camel@localhost.localdomain> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> Message-ID: <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> On 5/16/07, Toshio Kuratomi wrote: > On Wed, 2007-05-16 at 09:37 +0200, Hans de Goede wrote: > > Thus I would like to voice my concern over the web-form part of this. > > Preferably this would be handled in the makefile and when typing "make build" > > for a non-devel branch my $EDITOR would get launched opening a pre-filled > > template update anouncement, where I can add the necessary bits, and then upon > > saving this gets automatically entered into the updates system. > > > > Basicly every step added to the process is one too much, thus we should try to > > not add any steps if not absolutely necessary. Don't get me wrong, I'm not > > against using a proper updates scheme instead of the rolling model of extras > > (although that always worked well for me). But the whole workflow should be > > made as smooth as possible, as smooth as baby's buttocks preferably. > > Would a curses-style interface work for you? It looks like it would be > pretty easy to write a simple tui in python that first has you fill in > the fields similar to the web form, pops open your editor on a temp file > to enter/edit some freeform text, and then submits it to the update > system using JSON-RPC. Authenticating using the SSL certs might be a > bit harder but we could use passwords until that is resolved. If we're going down this road, I'd personally prefer a couple things. (And I find myself agreeing with most of what Ralf is saying here -- most of us aren't being paid for our work in Fedora... We should be aware of the impact these changes are having, and ensure that they're communicated and discussed with the community at large _prior_ to implementation! No one wants a repeat of the review process changes debacle.) * a "make push" command that could be run to push a package w/o any manual intervention. For most packages, a "make tag build push" would suffice, and the world wouldn't come to an end. * a simple cli tool to allow one's pending packages to be queried, and pushed in part or in full. This tool should have a non interactive mode (that is, be able to be run w/o requiring manual intervention). * a published remote interface that will allow people to write their own tools to manipulate the pending updates queue. I'm particularly impressed with the koji published api vs the plague one; this is a good trend. (Now, if I could just get more information on the bugzilla API...) In other words, a more robust updates system would seem to be a good thing -- but it's not always appropriate. Let's try to preserve the simplicity and efficientcy that has served Extras so well where we can. -Chris -- Chris Weyl Ex astris, scientia From jwboyer at jdub.homelinux.org Wed May 16 16:18:05 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 11:18:05 -0500 Subject: Updates System In-Reply-To: <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> Message-ID: <1179332285.13214.81.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote: > > * a "make push" command that could be run to push a package w/o any > manual intervention. For most packages, a "make tag build push" would > suffice, and the world wouldn't come to an end. That should never happen for updates. Packages are signed and you need a human to sign them. Automating the signing process is absurd because if that's done, there is no point in signing things anyway. For rawhide, "push" is irrelevant in a non-freeze cycle. josh From a.badger at gmail.com Wed May 16 16:24:46 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 May 2007 09:24:46 -0700 Subject: Updates System In-Reply-To: <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> Message-ID: <1179332686.2746.199.camel@localhost.localdomain> On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote: > On 5/16/07, Toshio Kuratomi wrote: > > On Wed, 2007-05-16 at 09:37 +0200, Hans de Goede wrote: > > > Thus I would like to voice my concern over the web-form part of this. > > > Preferably this would be handled in the makefile and when typing "make build" > > > for a non-devel branch my $EDITOR would get launched opening a pre-filled > > > template update anouncement, where I can add the necessary bits, and then upon > > > saving this gets automatically entered into the updates system. > > > > > > Basicly every step added to the process is one too much, thus we should try to > > > not add any steps if not absolutely necessary. Don't get me wrong, I'm not > > > against using a proper updates scheme instead of the rolling model of extras > > > (although that always worked well for me). But the whole workflow should be > > > made as smooth as possible, as smooth as baby's buttocks preferably. > > > > Would a curses-style interface work for you? It looks like it would be > > pretty easy to write a simple tui in python that first has you fill in > > the fields similar to the web form, pops open your editor on a temp file > > to enter/edit some freeform text, and then submits it to the update > > system using JSON-RPC. Authenticating using the SSL certs might be a > > bit harder but we could use passwords until that is resolved. > > If we're going down this road, I'd personally prefer a couple things. > (And I find myself agreeing with most of what Ralf is saying here -- > most of us aren't being paid for our work in Fedora... We should be > aware of the impact these changes are having, and ensure that they're > communicated and discussed with the community at large _prior_ to > implementation! No one wants a repeat of the review process changes > debacle.) > > * a "make push" command that could be run to push a package w/o any > manual intervention. For most packages, a "make tag build push" would > suffice, and the world wouldn't come to an end. > > * a simple cli tool to allow one's pending packages to be queried, and > pushed in part or in full. This tool should have a non interactive > mode (that is, be able to be run w/o requiring manual intervention). > > * a published remote interface that will allow people to write their > own tools to manipulate the pending updates queue. I'm particularly > impressed with the koji published api vs the plague one; this is a > good trend. (Now, if I could just get more information on the > bugzilla API...) > I'd like to see a way to do everything from the CLI non-interactively (or at most, with a command line switch for a message) as well. But I haven't been playing around enough with Bodhi to know if that is possible. Knowing the architecture it sits on, I know it will be simple to create a simple fill in the form application that can submit its data to Bodhi and work. The non-interactive CLI will be more work as it has to authenticate and have to make choices that are available on the web form like SECURITY/non-security, relevant Bug #'s, etc. Probably sane defaults will take care of the second issue and hopefully we can share code with koji to make auth work but it'll take more time to implement. > In other words, a more robust updates system would seem to be a good > thing -- but it's not always appropriate. Let's try to preserve the > simplicity and efficientcy that has served Extras so well where we > can. I don't quite agree with the first sentence but I agree wholeheartedly with the second. Having update announcements is always appropriate. Being able to do that in a simple and efficient manner in the default case is the goal that we need to satisfy. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Wed May 16 16:25:18 2007 From: opensource at till.name (Till Maas) Date: Wed, 16 May 2007 18:25:18 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <20070516143739.GF3228@free.fr> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <200705161035.54820.jkeating@redhat.com> <20070516143739.GF3228@free.fr> Message-ID: <200705161825.20102.opensource@till.name> On Mi Mai 16 2007, Patrice Dumas wrote: > On Wed, May 16, 2007 at 10:35:54AM -0400, Jesse Keating wrote: > > So make the change. It's a wiki. > > How could I make the change I don't know what is to be written! I don't > know what is the procedure to orphan in the merged world, that's what I > asked in my mail. I don't follow the infrastructure stuff (I follow it > only as a maintainer). I find myself in the same situation several times. For this reason, it would be nice to have a direct link on each official wiki page to the "personal page" of one, who knows what is correct on the page and how to correct this. Regards, Till From andreas at bawue.net Wed May 16 16:37:59 2007 From: andreas at bawue.net (Andreas Thienemann) Date: Wed, 16 May 2007 18:37:59 +0200 (CEST) Subject: [Patch] Adding Certificate Check to cvs-import.sh Message-ID: Hi, attached is a patch to cvs-import.sh which adds a check whether the ssl certificate is still valid. This should be helpful preventing strange "cannot check module on upload.cgi" messages. regards, andreas -------------- next part -------------- --- cvs-import.sh.orig 2007-05-16 12:48:55.000000000 +0200 +++ cvs-import.sh 2007-05-16 18:36:13.000000000 +0200 @@ -22,6 +22,20 @@ echo " from https://admin.fedora.redhat.com/accounts/" >&2 exit 1 fi + +# Check that the ssl certificate is not already expired or expiring in the +# next 10 minutes +OPENSSL=$(which openssl 2>/dev/null) +if [ -x ${OPENSSL} ]; then + ${OPENSSL} x509 -checkend 6000 -noout -in ${HOME}/.fedora.cert + if [ $? -ne 0 ]; then + echo "ERROR: Your Fedora client-side certificate expired." >&2 + echo " You need to download a new client-side certificate" >&2 + echo " from https://admin.fedora.redhat.com/accounts/" >&2 + exit 1 + fi +fi + # use the CVSROOT from the checkout CVSROOT=$(cat ${MYDIR}/CVS/Root) From cweyl at alumni.drew.edu Wed May 16 16:38:29 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 16 May 2007 09:38:29 -0700 Subject: Updates System In-Reply-To: <1179332285.13214.81.camel@zod.rchland.ibm.com> References: <200705141710.20460.jkeating@redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> <1179332285.13214.81.camel@zod.rchland.ibm.com> Message-ID: <7dd7ab490705160938g5420f864k5c58fb3dcf3bb395@mail.gmail.com> On 5/16/07, Josh Boyer wrote: > On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote: > > > > * a "make push" command that could be run to push a package w/o any > > manual intervention. For most packages, a "make tag build push" would > > suffice, and the world wouldn't come to an end. > > That should never happen for updates. Packages are signed and you need > a human to sign them. Automating the signing process is absurd because > if that's done, there is no point in signing things anyway. Sorry, push was definitely a misnomer here. Basically where I was going is that there should be some trivial way to flag an update as safe to tag with updates when built (or maybe after a day's delay, etc)... maybe something like 'make autotag' or somesuch. -Chris -- Chris Weyl Ex astris, scientia From rc040203 at freenet.de Wed May 16 16:46:51 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 18:46:51 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705161129.20554.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <1179327663.4735.735.camel@mccallum.corsepiu.local> <200705161129.20554.jkeating@redhat.com> Message-ID: <1179334012.4735.759.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 11:29 -0400, Jesse Keating wrote: > On Wednesday 16 May 2007 11:01:03 Ralf Corsepius wrote: > > ... imagine to rebuild several dozens of packages depending on a > > base-package for different versions of Fedora because something in the > > base-package has changed. > > > > e.g. reflecting the ongoing perl-split to dozens of perl-modules and > > wanting to keep the diffs minimal. Depending on how things are supposed > > to work out ... this will be very tedious. > > Which could all be issued as _one_ update. So one snippit to write for the > entire set. How to? URL? Ralf From dominik at greysector.net Wed May 16 16:50:08 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 16 May 2007 18:50:08 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705152252.18881.opensource@till.name> References: <4649F123.8070701@fedoraproject.org> <20070515201048.GD5928@ryvius.pekin.waw.pl> <200705151617.18565.jkeating@redhat.com> <200705152252.18881.opensource@till.name> Message-ID: <20070516165008.GB1036@ryvius.pekin.waw.pl> On Tuesday, 15 May 2007 at 22:52, Till Maas wrote: > On Di Mai 15 2007, Jesse Keating wrote: > > On Tuesday 15 May 2007 16:10:48 Dominik 'Rathann' Mierzejewski wrote: > > > $ koji request-tag f7-final packagename > > > > > > > > > would've been nice, though. > > > > Patches accepted (: > > After I found out that bodhi is a web-application, as soon as it is ready, it > would be very helpful to link directly from koji to it, e.g. a link on > http://koji.fedoraproject.org/koji/buildinfo?buildID=4418 > that links to > http://bodhi.fedoraproject.org/bodhi/new/915resolution-0.5.3-1.fc7 $ host bodhi.fedoraproject.org Host bodhi.fedoraproject.org not found: 3(NXDOMAIN) Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rc040203 at freenet.de Wed May 16 16:57:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 May 2007 18:57:33 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <20070516165250.3832c90e.bugs.michael@gmx.net> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> <20070516165250.3832c90e.bugs.michael@gmx.net> Message-ID: <1179334654.4735.767.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 16:52 +0200, Michael Schwendt wrote: > On Wed, 16 May 2007 14:22:30 +0200, Ralf Corsepius wrote: > > > I would have added you as co-maintainer of cvsutils in owners.list > > but apparently the procedures outlined on > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages?action=show&redirect=Extras%2FOrphanedPackages > > also do not apply anymore: > > 1) There has never been a separate Wiki page that covers owners.list. True. But I searched the wiki on "owners" because I had wanted to find out the current way of changing owner and found the page above. > 2) That you find the OrphanedPackages page during your search for > documentation on how to add package co-maintainers or new maintainers > adds confirmation for 1). True, when I found it, the page contained this: 1. Edit '''owners.list''' in Fedora Package CVS and set the ''initialowner'' field of your package to ''extras-orphan[AT]fedoraproject.org'' e-mail address (substitute the [AT] appropriately). This matched with what had been doing ever since FE had existed. > 3) The Fedora Extras community used to be able to control their packages, > including package ownership, co-ownership, and orphans. We used to be > able to handle all that ourselves. But recently, a cage has been set up > for the monkeys. Yes, this incident makes it apparent what certain circles think about the community. > Look in the list archives (February 20th), the message > with the subject "Orphanizing the OrphanedPackages Wiki page") is the > announcement that the page is unmaintained. And the page had not be updated. I'd really appreciate some professionalism and some people exhibiting responsibility. Ralf From nicolas.mailhot at laposte.net Wed May 16 17:08:09 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 16 May 2007 19:08:09 +0200 Subject: Updates System In-Reply-To: <1179332285.13214.81.camel@zod.rchland.ibm.com> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> <1179332285.13214.81.camel@zod.rchland.ibm.com> Message-ID: <1179335289.24448.10.camel@rousalka.dyndns.org> Le mercredi 16 mai 2007 ? 11:18 -0500, Josh Boyer a ?crit : > On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote: > > > > * a "make push" command that could be run to push a package w/o any > > manual intervention. For most packages, a "make tag build push" would > > suffice, and the world wouldn't come to an end. > > That should never happen for updates. Packages are signed and you need > a human to sign them. Automating the signing process is absurd because > if that's done, there is no point in signing things anyway. Of course there is. It's not as strong as manual signing but it prevents $random_script_kiddie dumping files on one of the numerous Fedora mirrors and have them propagated to user systems (Did the various auto-signing opponents ever bothered with a security audit of every Fedora mirror? Why would an attacker even bother with the root system when there are countless mirrors to attack?) Besides if someone manages to get access to the machine that does the signing, he can probably inject files in the root mirror whether they are signed or not, so you could as well advocate removing direct network feed of this system and require rel-eng to push the packages manually via a "secured" physical usb key. We all know manual signing is ideal. It's not practical for fedora-devel. And auto-signing is a hell more secure than no signing at all (on a similar vein refusing to do repotags bacause "filename" is not secure is ridiculous, filename is not secure with or without repotags, that's no reason not to have useful descriptive filemanes) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From wtogami at redhat.com Wed May 16 17:13:52 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 May 2007 13:13:52 -0400 Subject: Updates System In-Reply-To: <464AB4A7.6040209@hhs.nl> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> Message-ID: <464B3BD0.2010106@redhat.com> Hans de Goede wrote: > Ralf Corsepius wrote: >> On Wed, 2007-05-16 at 00:32 -0400, Warren Togami wrote: >>> Today Core updates happen using this update system. It is a smooth >>> and formal process. >> 0) maintainer tests package's functionality. >>> 1) Maintainer checks changes into CVS branch. >>> 2) Maintainer builds. >>> 3) Maintainer tests that build. >>> 4) Maintainer fills out the form with the N-V-R, optional security >>> (yes/no), optional Bug numbers fixed, and some fills in some details >>> of what the update is about, then chooses updates or updates-testing. >>> 5) Submit, where security and/or rel-eng team pushes it through. >> >> Now where in this scheme is Will Woods? I don't see him testing >> anything. All I see is more bureaucracy and more manual steps than >> before. >> > > As someone who maintains 125+ packages, I would like to show some > support for Ralf's point of view. I'm very proud of the fact that I not > only maintain 125+ packages, but also have 0 yes _zero_ open bugs > against them (most of the time), > call me Hans "zero open bugs" de Goede if you want :) > > However sometime real life intervenes and I cannot work on Fedora stuff > for a couple of days, when I then return to doing Fedora work, murphy > kicks in and I all off a sudden have 5 issues requesting my attention > (for some reason issues always come in bumps instead of as a steady > trickle), usually resulting in me pushing 4 a 5 bugfix updates in a > single day. > > Thus I would like to voice my concern over the web-form part of this. > Preferably this would be handled in the makefile and when typing "make > build" for a non-devel branch my $EDITOR would get launched opening a > pre-filled template update anouncement, where I can add the necessary > bits, and then upon saving this gets automatically entered into the > updates system. I agree that it can become problematic in the web form part of this. I think we will extend this to allow batch functionality possibly with a command line based tool. I believe that would dramatically shrink the time requirements and mitigate the concerns here. That being said, we wont have it immediately. Please reserve judgment until you actually see the system in action? I suspect you wont find it to be so bad. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Wed May 16 17:17:34 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 09:17:34 -0800 Subject: Updates System In-Reply-To: <464B3BD0.2010106@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <464B3BD0.2010106@redhat.com> Message-ID: <604aa7910705161017n278cf5e4qb35322e4aa960585@mail.gmail.com> On 5/16/07, Warren Togami wrote: > Please reserve judgment until you actually see the system in action? I > suspect you wont find it to be so bad. Would it be possible for someone, who has access to it nowish, to do up istanbul screencaptures and make some vids of interaction with it for a few common workflow cases? -jef"pimping istanbul, because i can"spaleta From wtogami at redhat.com Wed May 16 17:23:44 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 May 2007 13:23:44 -0400 Subject: Updates System In-Reply-To: <604aa7910705161017n278cf5e4qb35322e4aa960585@mail.gmail.com> References: <200705141710.20460.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <464B3BD0.2010106@redhat.com> <604aa7910705161017n278cf5e4qb35322e4aa960585@mail.gmail.com> Message-ID: <464B3E20.7030806@redhat.com> Jeff Spaleta wrote: > On 5/16/07, Warren Togami wrote: >> Please reserve judgment until you actually see the system in action? I >> suspect you wont find it to be so bad. > > Would it be possible for someone, who has access to it nowish, to do > up istanbul screencaptures and make some vids of interaction with it > for a few common workflow cases? > Has everyone seen the screenshots of bodhi? https://hosted.fedoraproject.org/projects/bodhi/wiki/Screenshots We wont have it immediately, but it would certainly possible to create optional faster interfaces that allow batch submission perhaps from the command line. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed May 16 17:24:11 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 May 2007 13:24:11 -0400 Subject: Update System: Not Rawhide Message-ID: <464B3E3B.9000105@redhat.com> Just to be sure that everyone is clear on this point: Update System is used *ONLY* for the workflow of updates during released distro and quite possibly during freezes. Rawhide builds go straight into the repo after they are built. Warren Togami wtogami at redhat.com From mmcgrath at redhat.com Wed May 16 17:26:51 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 16 May 2007 12:26:51 -0500 Subject: Outage Notification - 2007-05-17 04:00 [UTC] Message-ID: <464B3EDB.2070709@redhat.com> There will be an outage starting at 2007-05-17 04:00 [UTC], which will last approximately 1 hour. To convert UTC to your local time, use: http://www.timeanddate.com/worldclock/converter.html Affected Services: Buildsystem Unaffected Services: Websites CVS / Source Control Database DNS Mail Torrent Reason for Outage: Upgrading Koji to a new version and moving koji store to new hardware. This outage should be approximately 1 hour, maybe longer if the sync is running slower then expected. Will be coordinating in #fedora-admin The build system should either reject connections or queue connections during this time. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. From notting at redhat.com Wed May 16 17:41:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 16 May 2007 13:41:23 -0400 Subject: Update System: Not Rawhide In-Reply-To: <464B3E3B.9000105@redhat.com> References: <464B3E3B.9000105@redhat.com> Message-ID: <20070516174123.GD8430@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > Just to be sure that everyone is clear on this point: > > Update System is used *ONLY* for the workflow of updates during released > distro and quite possibly during freezes. Rawhide builds go straight > into the repo after they are built. ... outside of freeze periods, of course. Bill From ville.skytta at iki.fi Wed May 16 17:45:37 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 16 May 2007 20:45:37 +0300 Subject: Broken upgrade paths in F7 In-Reply-To: <20070515175133.783e5f32.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179237388.4735.486.camel@mccallum.corsepiu.local> <20070515175133.783e5f32.bugs.michael@gmx.net> Message-ID: <200705162045.37588.ville.skytta@iki.fi> On Tuesday 15 May 2007, Michael Schwendt wrote: > On Tue, 15 May 2007 15:56:28 +0200, Ralf Corsepius wrote: > > I.e. I consider all these EVR breakages rel-eng's fault and it to be > > their job to handle them - period. > > Hehe, I hope there will also be more unannounced broken deps in the builds > such as the ones I've had to reject/exclude again and again recently. > Unfortunately, we couldn't do fully automated checks, so when somebody > else pushed, some bad updates slipped through. Sorry for that, btw. My apologies too as I think I may have done some of those pushes - however I haven't been able to follow the evolution of the FE push scripts much at all lately, so I'm uncertain how does one sanely prevent things like this. If you have some recipes how to do it, it'd be nice if you could post them to extras-signers at . From nicolas.mailhot at laposte.net Wed May 16 18:03:07 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 16 May 2007 20:03:07 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705162045.37588.ville.skytta@iki.fi> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179237388.4735.486.camel@mccallum.corsepiu.local> <20070515175133.783e5f32.bugs.michael@gmx.net> <200705162045.37588.ville.skytta@iki.fi> Message-ID: <1179338587.25231.3.camel@rousalka.dyndns.org> BTW I'm seeing a strange thing right now: updated debuginfo packages are pushed, but the corresponding packages fail to appear in core. So right now I have some debuginfo packages more current than the corresponding binaries on-system (I wonder if that's going to screw up tracing; shouldn't debuginfo packages require the good EVR of instrumented packages by default to prevent this?) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From cweyl at alumni.drew.edu Wed May 16 18:13:39 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 16 May 2007 11:13:39 -0700 Subject: Updates System In-Reply-To: <464B3E20.7030806@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <464B3BD0.2010106@redhat.com> <604aa7910705161017n278cf5e4qb35322e4aa960585@mail.gmail.com> <464B3E20.7030806@redhat.com> Message-ID: <7dd7ab490705161113h2c3badc6rf4fe0d72a81d1667@mail.gmail.com> On 5/16/07, Warren Togami wrote: > We wont have it immediately, but it would certainly possible to create > optional faster interfaces that allow batch submission perhaps from the > command line. Based on this thread, I would suggest that a CLI tool be given significant priority and delivered with all deliberate speed.[1] Otherwise the good aspects of the web-based interface may not be evaluated at face value due to discontent in other areas, and I don't believe anyone wants that to happen. (I certainly don't.) -Chris [1] Or, at least, the API to the system be published and open. If that's done, the market (as it were) may very well solve the problem on its own... -- Chris Weyl Ex astris, scientia From mr.ecik at gmail.com Wed May 16 18:14:29 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Wed, 16 May 2007 20:14:29 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <1179319488.13214.21.camel@zod.rchland.ibm.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> Message-ID: <668bb39a0705161114p5751d98o817c4e403562245d@mail.gmail.com> 2007/5/16, Josh Boyer : > sonata: > FE6 > F7 (0:1.1-1.fc6 > 0:1.0.1-3.fc7) > sonata-1.1-1.fc7 dist-fc7 ecik I sent a request to rel-eng to include it. -- Micha? Bentkowski mr.ecik at gmail.com From ville.skytta at iki.fi Wed May 16 18:18:06 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 16 May 2007 21:18:06 +0300 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151258.19145.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <200705151823.34570.opensource@till.name> <200705151258.19145.jkeating@redhat.com> Message-ID: <200705162118.06772.ville.skytta@iki.fi> On Tuesday 15 May 2007, Jesse Keating wrote: > On Tuesday 15 May 2007 12:23:33 Till Maas wrote: > > Will it possible to tell yum to only perform security updates then? E.g. > > do "yum --type security update" or something similiar? > > That is a possibility. The metadata about the update actually lives in the > yum repodata so things like that are definitely possible. Hmm, I was unaware of that. What does a packager need to do in order to have a package update end up in repodata marked as a security update? From jwboyer at jdub.homelinux.org Wed May 16 18:18:27 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 13:18:27 -0500 Subject: Updates System In-Reply-To: <7dd7ab490705161113h2c3badc6rf4fe0d72a81d1667@mail.gmail.com> References: <200705141710.20460.jkeating@redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <464B3BD0.2010106@redhat.com> <604aa7910705161017n278cf5e4qb35322e4aa960585@mail.gmail.com> <464B3E20.7030806@redhat.com> <7dd7ab490705161113h2c3badc6rf4fe0d72a81d1667@mail.gmail.com> Message-ID: <1179339507.13214.100.camel@zod.rchland.ibm.com> On Wed, 2007-05-16 at 11:13 -0700, Chris Weyl wrote: > On 5/16/07, Warren Togami wrote: > > We wont have it immediately, but it would certainly possible to create > > optional faster interfaces that allow batch submission perhaps from the > > command line. > > Based on this thread, I would suggest that a CLI tool be given > significant priority and delivered with all deliberate speed.[1] > Otherwise the good aspects of the web-based interface may not be > evaluated at face value due to discontent in other areas, and I don't > believe anyone wants that to happen. (I certainly don't.) > > -Chris > > [1] Or, at least, the API to the system be published and open. If > that's done, the market (as it were) may very well solve the problem > on its own... https://hosted.fedoraproject.org/projects/bodhi Given that the person currently writing the tool is in the middle of taking exams for school "deliberate speed" is already as fast as he can go. Patches welcome. josh From katzj at redhat.com Wed May 16 18:14:37 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 16 May 2007 14:14:37 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705162118.06772.ville.skytta@iki.fi> References: <200705141710.20460.jkeating@redhat.com> <200705151823.34570.opensource@till.name> <200705151258.19145.jkeating@redhat.com> <200705162118.06772.ville.skytta@iki.fi> Message-ID: <1179339277.29031.2.camel@aglarond.local> On Wed, 2007-05-16 at 21:18 +0300, Ville Skytt? wrote: > On Tuesday 15 May 2007, Jesse Keating wrote: > > On Tuesday 15 May 2007 12:23:33 Till Maas wrote: > > > Will it possible to tell yum to only perform security updates then? E.g. > > > do "yum --type security update" or something similiar? > > > > That is a possibility. The metadata about the update actually lives in the > > yum repodata so things like that are definitely possible. > > Hmm, I was unaware of that. What does a packager need to do in order to have > a package update end up in repodata marked as a security update? As of today with an Extras package, there's no way to do so. That's one of the things using bodhi for pushing updates to released distros will give us. Jeremy From Michael_E_Brown at dell.com Wed May 16 18:27:59 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 16 May 2007 13:27:59 -0500 Subject: Updates System In-Reply-To: <1179339507.13214.100.camel@zod.rchland.ibm.com> References: <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <464B3BD0.2010106@redhat.com> <604aa7910705161017n278cf5e4qb35322e4aa960585@mail.gmail.com> <464B3E20.7030806@redhat.com> <7dd7ab490705161113h2c3badc6rf4fe0d72a81d1667@mail.gmail.com> <1179339507.13214.100.camel@zod.rchland.ibm.com> Message-ID: <20070516182759.GE10135@humbolt.us.dell.com> On Wed, May 16, 2007 at 01:18:27PM -0500, Josh Boyer wrote: > On Wed, 2007-05-16 at 11:13 -0700, Chris Weyl wrote: > > On 5/16/07, Warren Togami wrote: > > > We wont have it immediately, but it would certainly possible to create > > > optional faster interfaces that allow batch submission perhaps from the > > > command line. > > > > Based on this thread, I would suggest that a CLI tool be given > > significant priority and delivered with all deliberate speed.[1] > > Otherwise the good aspects of the web-based interface may not be > > evaluated at face value due to discontent in other areas, and I don't > > believe anyone wants that to happen. (I certainly don't.) > > > > -Chris > > > > [1] Or, at least, the API to the system be published and open. If > > that's done, the market (as it were) may very well solve the problem > > on its own... > > https://hosted.fedoraproject.org/projects/bodhi > > Given that the person currently writing the tool is in the middle of > taking exams for school "deliberate speed" is already as fast as he can > go. http://mw1.merriam-webster.com/dictionary deliberate: ... cut ... 3 : slow, unhurried, and steady as though allowing time for decision on each individual action involved -- Michael From bugs.michael at gmx.net Wed May 16 18:29:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Wed, 16 May 2007 20:29:57 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <1179334654.4735.767.camel@mccallum.corsepiu.local> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> <20070516165250.3832c90e.bugs.michael@gmx.net> <1179334654.4735.767.camel@mccallum.corsepiu.local> Message-ID: <20070516202957.019722a1.bugs.michael@gmx.net> On Wed, 16 May 2007 18:57:33 +0200, Ralf Corsepius wrote: > > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > > Look in the list archives (February 20th), the message > > with the subject "Orphanizing the OrphanedPackages Wiki page") is the > > announcement that the page is unmaintained. > > And the page had not be updated. I'd really appreciate some > professionalism and some people exhibiting responsibility. Well, what update? A warning at the top that "mschwendt no longer is subscribed to the page"? ;o) That would be strange. It's a Wiki. Anyone [in EditGroup] can touch the page and update it if things are out-of-date. And handling orphans and related cleanup [1] is something somebody else might have wanted to do. In retrospect, I should have deleted the page. There have never been official policies on orphaned packages, because it's a topic that hasn't seen buy-in from [Extras'] FESCo. [1] Editing owners.list when packagers announced orphans without updating owners.list. Announcing discovered orphans which have gone unnoticed for various reasons. Reassigning and replying to tickets filed about orphans. Marking orphans dead.package prior to next branch of devel. Deleting long-time orphans from the repositories. From notting at redhat.com Wed May 16 18:28:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 16 May 2007 14:28:47 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179338587.25231.3.camel@rousalka.dyndns.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179237388.4735.486.camel@mccallum.corsepiu.local> <20070515175133.783e5f32.bugs.michael@gmx.net> <200705162045.37588.ville.skytta@iki.fi> <1179338587.25231.3.camel@rousalka.dyndns.org> Message-ID: <20070516182847.GG8430@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > BTW I'm seeing a strange thing right now: updated debuginfo packages are > pushed, but the corresponding packages fail to appear in core. So right > now I have some debuginfo packages more current than the corresponding > binaries on-system (I wonder if that's going to screw up tracing; > shouldn't debuginfo packages require the good EVR of instrumented > packages by default to prevent this?) Is your mirror mid-sync? Bill From Axel.Thimm at ATrpms.net Wed May 16 18:52:14 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 16 May 2007 20:52:14 +0200 Subject: (non) automatic signing (was: Updates System) In-Reply-To: <1179335289.24448.10.camel@rousalka.dyndns.org> References: <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> <1179332285.13214.81.camel@zod.rchland.ibm.com> <1179335289.24448.10.camel@rousalka.dyndns.org> Message-ID: <20070516185214.GF19921@neu.nirvana> On Wed, May 16, 2007 at 07:08:09PM +0200, Nicolas Mailhot wrote: > Le mercredi 16 mai 2007 ? 11:18 -0500, Josh Boyer a ?crit : > > On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote: > > > > > > * a "make push" command that could be run to push a package w/o any > > > manual intervention. For most packages, a "make tag build push" would > > > suffice, and the world wouldn't come to an end. > > > > That should never happen for updates. Packages are signed and you need > > a human to sign them. Automating the signing process is absurd because > > if that's done, there is no point in signing things anyway. > > Of course there is. > [...] I was just going to write what Nicolas did. In fact even to the letter. Maybe we are twin brothers after all and our parents lied to us ;) Anyway to add something to the discussion: ATrpms does automated signing since the beginning and according to the logic "If someone compromizes the signing system it doesn't matter if he retrieves a passphrase-less key or waits until he sniffs the passphrase off my fingers" it is really not helping to slow-down the process by manual signing. In fact one could even argue that automated signing is more secure that manual: In the automated signing setup, the attacker needs to hack into one system. In the manual setup, he can choose between the signing server and my laptop. More choices for the attacker means more possible entry points. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed May 16 19:08:45 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 11:08:45 -0800 Subject: Update System: Not Rawhide In-Reply-To: <464B3E3B.9000105@redhat.com> References: <464B3E3B.9000105@redhat.com> Message-ID: <604aa7910705161208r73eb3e3fp4aab37ad78690c38@mail.gmail.com> On 5/16/07, Warren Togami wrote: > Just to be sure that everyone is clear on this point: > > Update System is used *ONLY* for the workflow of updates during released > distro and quite possibly during freezes. does 'updates' also mean initial versions of a new component added to a released distro? -jef From bpepple at fedoraproject.org Wed May 16 19:11:09 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 16 May 2007 15:11:09 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting Message-ID: <1179342669.5813.16.camel@lincoln> Hi, I guessing the turnout for tomorrow's meeting will be pretty light, due to this week's Red Hat Summit. Anyway, please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- F7 Preparations /topic FESCO-Meeting -- MISC -- Compat policy for future /topic FESCO-Meeting -- MISC -- Policies that need updating for merge? -- http://fedoraproject.org/wiki/PackageMaintainers/Policy /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed May 16 19:15:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 16 May 2007 21:15:14 +0200 Subject: (non) automatic signing (was: Updates System) In-Reply-To: <20070516185214.GF19921@neu.nirvana> References: <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <1179309483.2746.186.camel@localhost.localdomain> <7dd7ab490705160902oc1c0cfeyb958e52e1907f052@mail.gmail.com> <1179332285.13214.81.camel@zod.rchland.ibm.com> <1179335289.24448.10.camel@rousalka.dyndns.org> <20070516185214.GF19921@neu.nirvana> Message-ID: <1179342914.26674.3.camel@rousalka.dyndns.org> Le mercredi 16 mai 2007 ? 20:52 +0200, Axel Thimm a ?crit : > On Wed, May 16, 2007 at 07:08:09PM +0200, Nicolas Mailhot wrote: > > Le mercredi 16 mai 2007 ? 11:18 -0500, Josh Boyer a ?crit : > > > On Wed, 2007-05-16 at 09:02 -0700, Chris Weyl wrote: > > > > > > > > * a "make push" command that could be run to push a package w/o any > > > > manual intervention. For most packages, a "make tag build push" would > > > > suffice, and the world wouldn't come to an end. > > > > > > That should never happen for updates. Packages are signed and you need > > > a human to sign them. Automating the signing process is absurd because > > > if that's done, there is no point in signing things anyway. > > > > Of course there is. > > > [...] > > I was just going to write what Nicolas did. In fact even to the > letter. Maybe we are twin brothers after all and our parents lied to > us ;) Oh, no, I'm Axelefying! /me checks the water tap for radioactive elements :) > Anyway to add something to the discussion: ATrpms does automated > signing since the beginning And kernel.org autosigns too. Anyone wants to pretend that system has not been audited to death? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kwizart at gmail.com Wed May 16 19:36:23 2007 From: kwizart at gmail.com (KH KH) Date: Wed, 16 May 2007 21:36:23 +0200 Subject: Request for comaintainers In-Reply-To: References: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> Message-ID: 2007/5/16, KH KH : > 2007/5/15, Jochen Schmitt : > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hello, > > > > I'm search comaintainsers for this packages: > > > > - - aplus-fsf > > - - blender > Hello > I sure blender might bring some interest! > It has been recently updated to 2.44 (with a bugfix release for 2.43 > about x86_64) > I will start to do some work with these version on x86_64... > (quite sure there is a need to break the deep freeze about this > package and x86_64 support...) > I currently maintain aqsis so i'm interested in blender and how it can > interact with it... > > > - - crossvc > > - - gnu-smalltalk > > - - gprolog > > - - highlight > > - - inadyn > > - - kyum > > - - lightning > > - - luma > > - - pdftk > > - - steghide > > - - stellarium > > - - suck > > I have some interest in stellarium but i know less others ones... > (i will quick look some of them...) > > Nicolas (kwizart) > > PS: About kyum, Someone on the french forum reported that it has > deleted my repository definition: kwizart.repo. I will sanity check > it ... But i'm not a kde user usually... > I haven't done any test about this bug yet: (only tested rel -1) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239467 http://kwizart.free.fr/fedora/7/testing/blender/ That would be really fine to have 2.44 on F7 Then we could work on a 2.43 for FC-6 (FC-5)... Nicolas (kwizart) From jkeating at redhat.com Wed May 16 20:03:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 16:03:49 -0400 Subject: Update System: Not Rawhide In-Reply-To: <604aa7910705161208r73eb3e3fp4aab37ad78690c38@mail.gmail.com> References: <464B3E3B.9000105@redhat.com> <604aa7910705161208r73eb3e3fp4aab37ad78690c38@mail.gmail.com> Message-ID: <200705161603.52743.jkeating@redhat.com> On Wednesday 16 May 2007 15:08:45 Jeff Spaleta wrote: > does 'updates' also mean initial versions of a new component added to > a released distro? Yes. Hurray! New package discovery/announcement! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed May 16 20:08:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 16:08:45 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179334012.4735.759.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <200705161129.20554.jkeating@redhat.com> <1179334012.4735.759.camel@mccallum.corsepiu.local> Message-ID: <200705161608.45793.jkeating@redhat.com> On Wednesday 16 May 2007 12:46:51 Ralf Corsepius wrote: > How to? URL? As I said before, the documentation doesn't quite exist. As others have stated, the author is currently taking exams at college and that has a slightly higher priority. Patience is a valueable virtue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Wed May 16 20:04:55 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 22:04:55 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179272593.2746.89.camel@localhost.localdomain> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> Message-ID: <20070516200454.GB2890@free.fr> On Tue, May 15, 2007 at 04:43:13PM -0700, Toshio Kuratomi wrote: > > Unless a guideline is marked as a "should" it is mandatory. If you > disagree with something the guidelines say is a must, the proper thing > to do is to get the guideline changed.[1]_ For the static libraries, I voiced my concerns on fedora-packaging, Ralf responded without answering my arguments, I reresponded and nothing happened after that. Although there had been a big thread were my point appeared clearly, and more recently in another thread about static libs naming. Now I am tired to relaunch the subject just to have nobody answering anything relevant, so I bypass the guidelines. > For changelogs, the guidelines say: "Every time you make changes, that > is, whenever you increment the E-V-R of a package, add a changelog > entry." > This means you must write a changelog entry. The reasons are given in > the guidelines [2]_. Sometimes it is silly to add a changelog entry in that case I don't add a changelog entry, period. (You can have a look at my cvs commit entries for example see recent commit for the cernlib if you like ti understand why). > For static libraries, the guidelines recognize that there may be > instances where static libraries are desirable. If you want to either > provide static libraries in a subpackage or to link against static > libraries you must ask FESCo for permission. This check was written for > several reasons: > > 1) static libraries are a security hazard and there is a strong desire > to keep the libraries from being linked into packages provided by > Fedora. This check helps FESCo and the packaging committee enforce > this. Moot for numerical libraries. > 2) The Packaging Committee realized that there are packages that need to > contravene this policy but not how many. If there are hundreds of > libraries in Fedora requesting to ship static libraries then the > guideline must be revised to accommodate them. If it's only a dozen > then having exceptions for those packages is sufficient. I always said that I agreed to report to FESCo that I ship a static lib, but that it was silly to ask FESCo when I know better, and I won't do it. > 3) The Packaging Committee realized that this draft could be made better > if we could draft a statement that covered the valid cases without > letting packages without sufficient reasons in. However we didn't have > a large enough sample of valid packages to be able to write that yet. > By having this reported we would be able to gather information on what > rule could be made to fit this. There is at least the cernlib, the gsl, lapack, blas, and certainly netcdf, hdf. Some packages have static libs because upstream doesn't provide a shared lib, like (packages I know because I maintain them) libnet10, libnet. It is quite unfortunate in that case but I have argued a lot of time why I think it is better not to introduce shared libs in fedora at that point. > Deciding "not to bother FESCo" with this is not saving us time; it is > making it so someone down the line has to spend time finding which > packages are linking against static libraries without an exemption and > figure out what the proper fix is. That's wrong. No package will ever link against static libs when there are shared libs. And I agree that static packages in -static packages is right in most cases (I think that for the cernlib it is not right so I made an exception for that lib, but this is a very specific case) so this is doubly wrong. > ''' > The Packaging Guidelines are a collection of common issues and the > severity that should be placed on them. While these guidelines should > not be ignored, they should also not be blindly followed. If you think > that your package should be exempt from part of the Guidelines, please > bring the issue to the Fedora Packaging Committee. > ''' I did it without success. -- Pat From katzj at redhat.com Wed May 16 20:31:02 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 16 May 2007 16:31:02 -0400 Subject: [Patch] Adding Certificate Check to cvs-import.sh In-Reply-To: References: Message-ID: <1179347462.2025.20.camel@erebor.boston.redhat.com> On Wed, 2007-05-16 at 18:37 +0200, Andreas Thienemann wrote: > attached is a patch to cvs-import.sh which adds a check whether the ssl > certificate is still valid. Awesome! Thanks for sitting down and figuring out the openssl incantations to do this. I've gone ahead and committed the change to cvs-import.sh and then also integrated it into Makefile.common so that things there will also catch the case. Jeremy From sundaram at fedoraproject.org Wed May 16 20:35:31 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 02:05:31 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070516200454.GB2890@free.fr> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> Message-ID: <464B6B13.7060604@fedoraproject.org> Patrice Dumas wrote: > On Tue, May 15, 2007 at 04:43:13PM -0700, Toshio Kuratomi wrote: >> Unless a guideline is marked as a "should" it is mandatory. If you >> disagree with something the guidelines say is a must, the proper thing >> to do is to get the guideline changed.[1]_ > > For the static libraries, I voiced my concerns on fedora-packaging, Ralf > responded without answering my arguments, I reresponded and nothing > happened after that. Although there had been a big thread were my point > appeared clearly, and more recently in another thread about static libs > naming. Now I am tired to relaunch the subject just to have nobody > answering anything relevant, so I bypass the guidelines. Bypassing MUST sections of the guidelines like this is just plain wrong. If every maintainer can bypass the guidelines whenever they want there is no point in having the guidelines. Rahul From jspaleta at gmail.com Wed May 16 20:51:32 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 12:51:32 -0800 Subject: Update System: Not Rawhide In-Reply-To: <200705161603.52743.jkeating@redhat.com> References: <464B3E3B.9000105@redhat.com> <604aa7910705161208r73eb3e3fp4aab37ad78690c38@mail.gmail.com> <200705161603.52743.jkeating@redhat.com> Message-ID: <604aa7910705161351l5d9a82bfy8461fbdc26c26d0a@mail.gmail.com> On 5/16/07, Jesse Keating wrote: > On Wednesday 16 May 2007 15:08:45 Jeff Spaleta wrote: > > does 'updates' also mean initial versions of a new component added to > > a released distro? > > Yes. Hurray! New package discovery/announcement! I very much will like that. I'm personally more interested in reading daily digests of new packages with a cup of coffee in hand in the morning than update notices. -jef From pertusus at free.fr Wed May 16 20:43:20 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 22:43:20 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464B6B13.7060604@fedoraproject.org> References: <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <464B6B13.7060604@fedoraproject.org> Message-ID: <20070516204320.GC2890@free.fr> On Thu, May 17, 2007 at 02:05:31AM +0530, Rahul Sundaram wrote: > > Bypassing MUST sections of the guidelines like this is just plain wrong. > If every maintainer can bypass the guidelines whenever they want there > is no point in having the guidelines. Ignoring valid concerns about the guidelines isn't better. It is not about bypassing the guidelines whenever I want, there were discussions about the relevance of static libs in some contexts, but nobody seems to care in the FPC. I bypassed the guidelines only after this became evident. In most cases I follow the guidelines to the letter. -- Pat From sundaram at fedoraproject.org Wed May 16 21:04:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 02:34:07 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070516204320.GC2890@free.fr> References: <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <464B6B13.7060604@fedoraproject.org> <20070516204320.GC2890@free.fr> Message-ID: <464B71C7.8090400@fedoraproject.org> Patrice Dumas wrote: > On Thu, May 17, 2007 at 02:05:31AM +0530, Rahul Sundaram wrote: >> Bypassing MUST sections of the guidelines like this is just plain wrong. >> If every maintainer can bypass the guidelines whenever they want there >> is no point in having the guidelines. > > Ignoring valid concerns about the guidelines isn't better. It isn't. Hence the guidelines should be fixed. Not bypassed. Rahul From pertusus at free.fr Wed May 16 21:01:23 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 23:01:23 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464B71C7.8090400@fedoraproject.org> References: <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <464B6B13.7060604@fedoraproject.org> <20070516204320.GC2890@free.fr> <464B71C7.8090400@fedoraproject.org> Message-ID: <20070516210123.GF2890@free.fr> On Thu, May 17, 2007 at 02:34:07AM +0530, Rahul Sundaram wrote: > > It isn't. Hence the guidelines should be fixed. Not bypassed. After dome time with nobody moving I consider that it is more efficient to bypass than to watch the issue not being solved. -- Pat From sundaram at fedoraproject.org Wed May 16 21:12:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 17 May 2007 02:42:43 +0530 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070516210123.GF2890@free.fr> References: <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <464B6B13.7060604@fedoraproject.org> <20070516204320.GC2890@free.fr> <464B71C7.8090400@fedoraproject.org> <20070516210123.GF2890@free.fr> Message-ID: <464B73CB.4080608@fedoraproject.org> Patrice Dumas wrote: > On Thu, May 17, 2007 at 02:34:07AM +0530, Rahul Sundaram wrote: >> It isn't. Hence the guidelines should be fixed. Not bypassed. > > After dome time with nobody moving I consider that it is more efficient > to bypass than to watch the issue not being solved. That "solves" your instances. Everybody else will be running across the same set of issues. Rahul From pertusus at free.fr Wed May 16 21:13:24 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 May 2007 23:13:24 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <464B73CB.4080608@fedoraproject.org> References: <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <464B6B13.7060604@fedoraproject.org> <20070516204320.GC2890@free.fr> <464B71C7.8090400@fedoraproject.org> <20070516210123.GF2890@free.fr> <464B73CB.4080608@fedoraproject.org> Message-ID: <20070516211324.GG2890@free.fr> On Thu, May 17, 2007 at 02:42:43AM +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: > >On Thu, May 17, 2007 at 02:34:07AM +0530, Rahul Sundaram wrote: > >>It isn't. Hence the guidelines should be fixed. Not bypassed. > > > >After dome time with nobody moving I consider that it is more efficient > >to bypass than to watch the issue not being solved. > > That "solves" your instances. Everybody else will be running across the > same set of issues. At least I will stop losing time and I won't make FESCo members lose time, I cannot do more individually. -- Pat From cweyl at alumni.drew.edu Wed May 16 23:02:13 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 16 May 2007 16:02:13 -0700 Subject: Update System: Not Rawhide In-Reply-To: <20070516174123.GD8430@nostromo.devel.redhat.com> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> Message-ID: <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> On 5/16/07, Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: > > Just to be sure that everyone is clear on this point: > > > > Update System is used *ONLY* for the workflow of updates during released > > distro and quite possibly during freezes. Rawhide builds go straight > > into the repo after they are built. > > ... outside of freeze periods, of course. Can't we branch before freeze? Wouldn't that obviate the need for freezing rawhide? -Chris -- Chris Weyl Ex astris, scientia From jkeating at redhat.com Wed May 16 23:07:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 May 2007 19:07:06 -0400 Subject: Update System: Not Rawhide In-Reply-To: <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> Message-ID: <200705161907.06342.jkeating@redhat.com> On Wednesday 16 May 2007 19:02:13 Chris Weyl wrote: > Can't we branch before freeze? ?Wouldn't that obviate the need for > freezing rawhide? I do believe the future plan is to let folks branch when they need to, since not everybody wants to have yet another branch to apply fixes to for the last month+ of a release. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed May 16 23:06:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 16 May 2007 18:06:39 -0500 Subject: Update System: Not Rawhide In-Reply-To: <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> Message-ID: <1179356799.8746.10.camel@vader.jdub.homelinux.org> On Wed, 2007-05-16 at 16:02 -0700, Chris Weyl wrote: > On 5/16/07, Bill Nottingham wrote: > > Warren Togami (wtogami at redhat.com) said: > > > Just to be sure that everyone is clear on this point: > > > > > > Update System is used *ONLY* for the workflow of updates during released > > > distro and quite possibly during freezes. Rawhide builds go straight > > > into the repo after they are built. > > > > ... outside of freeze periods, of course. > > Can't we branch before freeze? Wouldn't that obviate the need for > freezing rawhide? I think that's been suggested about 6 times now. And the answer was always "we discussed that". But I cannot for the life of me remember where and when and what the reasons were. josh From cweyl at alumni.drew.edu Thu May 17 00:02:08 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 16 May 2007 17:02:08 -0700 Subject: Update System: Not Rawhide In-Reply-To: <200705161907.06342.jkeating@redhat.com> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> <200705161907.06342.jkeating@redhat.com> Message-ID: <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> On 5/16/07, Jesse Keating wrote: > On Wednesday 16 May 2007 19:02:13 Chris Weyl wrote: > > Can't we branch before freeze? Wouldn't that obviate the need for > > freezing rawhide? > > I do believe the future plan is to let folks branch when they need to, since > not everybody wants to have yet another branch to apply fixes to for the last > month+ of a release. In such a scenario, would packages that branch prior to a mandated "must branch by" date still find themselves frozen in devel? If so, it wouldn't seem to help much... One would think we'd pursue this sort of pre-freeze branching, as it would probably tend to get people in the mindset of "hey, this isn't me noodling around in rawhide anymore, but a package targeted for actual release". -Chris -- Chris Weyl Ex astris, scientia From a.badger at gmail.com Thu May 17 00:35:11 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 May 2007 17:35:11 -0700 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070516200454.GB2890@free.fr> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> Message-ID: <1179362111.2746.311.camel@localhost.localdomain> On Wed, 2007-05-16 at 22:04 +0200, Patrice Dumas wrote: > On Tue, May 15, 2007 at 04:43:13PM -0700, Toshio Kuratomi wrote: > > > > Unless a guideline is marked as a "should" it is mandatory. If you > > disagree with something the guidelines say is a must, the proper thing > > to do is to get the guideline changed.[1]_ > > For the static libraries, I voiced my concerns on fedora-packaging, Ralf > responded without answering my arguments, I reresponded and nothing > happened after that. Although there had been a big thread were my point > appeared clearly, and more recently in another thread about static libs > naming. Now I am tired to relaunch the subject just to have nobody > answering anything relevant, so I bypass the guidelines. > The static-libs naming was resolved on list with no guidelines changes needing to be made. The static library thread basically came to the same place that we are at here. You have to follow the Guidelines. The reasons that the guidelines are written as they are is in Ralf's email and in this current exchange. By following the Guidelines you can help get them to change. Bypassing the guidelines as you are doing is just going to lead us to Packaging Armageddon with each rule being violated by those that disagree with it. This has to stop. > > For changelogs, the guidelines say: "Every time you make changes, that > > is, whenever you increment the E-V-R of a package, add a changelog > > entry." > > This means you must write a changelog entry. The reasons are given in > > the guidelines [2]_. > > Sometimes it is silly to add a changelog entry in that case I don't add > a changelog entry, period. (You can have a look at my cvs commit entries > for example see recent commit for the cernlib if you like ti understand > why). > Express an example of silliness and present a draft with the example as something that should be allowed. However, the attitude that there are some changes that are too silly to be recorded in the changelog is exactly why the people that voted for the changelog guideline voted for it. You are violating the spirit of the guideline as well as the letter by not putting a changelog entry in and I think your draft, example, and arguments will have to be very persuasive in order to make a change to this guideline. > > For static libraries, the guidelines recognize that there may be > > instances where static libraries are desirable. If you want to either > > provide static libraries in a subpackage or to link against static > > libraries you must ask FESCo for permission. This check was written for > > several reasons: > > > > 1) static libraries are a security hazard and there is a strong desire > > to keep the libraries from being linked into packages provided by > > Fedora. This check helps FESCo and the packaging committee enforce > > this. > > Moot for numerical libraries. > > > 2) The Packaging Committee realized that there are packages that need to > > contravene this policy but not how many. If there are hundreds of > > libraries in Fedora requesting to ship static libraries then the > > guideline must be revised to accommodate them. If it's only a dozen > > then having exceptions for those packages is sufficient. > > I always said that I agreed to report to FESCo that I ship a static lib, > but that it was silly to ask FESCo when I know better, and I won't do it. > Then you are not in compliance with the guidelines. The Packaging Committee itself has no teeth to enforce them. FESCo will have to decide if it wants to enforce the guidelines, delegate that power, or let the guidelines be informational rather than binding. > > 3) The Packaging Committee realized that this draft could be made better > > if we could draft a statement that covered the valid cases without > > letting packages without sufficient reasons in. However we didn't have > > a large enough sample of valid packages to be able to write that yet. > > By having this reported we would be able to gather information on what > > rule could be made to fit this. > > There is at least the cernlib, the gsl, lapack, blas, and certainly > netcdf, hdf. > > Some packages have static libs because upstream doesn't provide a shared > lib, like (packages I know because I maintain them) libnet10, libnet. > It is quite unfortunate in that case but I have argued a lot of time why > I think it is better not to introduce shared libs in fedora at that > point. > > > Deciding "not to bother FESCo" with this is not saving us time; it is > > making it so someone down the line has to spend time finding which > > packages are linking against static libraries without an exemption and > > figure out what the proper fix is. > > That's wrong. No package will ever link against static libs when there > are shared libs. And I agree that static packages in -static packages > is right in most cases (I think that for the cernlib it is not right > so I made an exception for that lib, but this is a very specific case) > so this is doubly wrong. > Not true. A Makefile can do whatever it wants. A spec file is also just a shell script when it comes down to it. > > ''' > > The Packaging Guidelines are a collection of common issues and the > > severity that should be placed on them. While these guidelines should > > not be ignored, they should also not be blindly followed. If you think > > that your package should be exempt from part of the Guidelines, please > > bring the issue to the Fedora Packaging Committee. > > ''' > > I did it without success. No. You did it without succeeding in getting the guidelines changed. You have a minority opinion. So you have to do some legwork to get the majority to come over to your viewpoint. The most effective way to do that in this case is not to write arguments to the mailing list. The most effective way is to follow the guidelines and thereby amass a body of packaging that supports your statements and shows what changes need to be written into the guidelines. You claim that the guidelines should be changed to allow numerical libraries to ship static libs but I can honestly say that FESCo has not been asked to allow one numerical library to ship a static library since the guideline went into effect. By bypassing the guidelines you're making it so we are unaware of the problems with the guidelines and denying us the data to change the guidelines to be better. We've left a door wide open for you to effect a change. Write a letter that says "These are numerical libraries, ie, ones that [Distinguishing features that make them relevant to this discussion]. As such they should be allowed to (ship|link) a static library." Take your list of libraries from above and add them to the form letter. Send it to FESCo as a reply to "Plan for tomorrows (20070517) FESCO meeting" as an agenda item like "Packages needing static libraries". Then FESCo or the Packaging Committee can evaluate the magnitude of the problem and attempt to reword the guideline to accommodate them. Once that's done, write another letter that says "These libraries have no shared libraries upstream. Thus they need to ship static libraries." and repeat. There are several things that can result from this: 1) Your reasons for thinking these libraries are special won't be seen by FESCo so they'll be denied. (Be sure to make your arguments persuasive and descriptive and if possible show up for the meeting where this is discussed :-) 2) FESCo will simply allow the libraries through without a fuss. You're neither better off nor worse off than before. 3) FESCo will not want to deal with this everytime a numerical library is reviewed. Seeing that you've extracted the important bits that define a numerical library and why it is in need of static libraries, they'll forward it on to the packaging committee to revise the guidelines so they don't have to deal with approving libraries of these types anymore. Nobody likes to do more work than they have to. Assuming your description of what makes the libraries in question deserving of shipping in static form is sufficient to show why and how the rules can be amended to allow the kind of libraries you are requesting through, I can't imagine that FESCo won't send the definition of numerical library on to the Packaging Committee. It is, after all, why the rules were drafted the way they are. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Thu May 17 00:36:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 May 2007 17:36:37 -0700 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179342669.5813.16.camel@lincoln> References: <1179342669.5813.16.camel@lincoln> Message-ID: <1179362197.2746.313.camel@localhost.localdomain> On Wed, 2007-05-16 at 15:11 -0400, Brian Pepple wrote: > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics in the meeting while it is in the "Free > discussion around Fedora" phase. I think we need to discuss whether the Packaging Guidelines are only Guidelines or if they're Rules. If the latter, whether we're willing to take any actions to enforce them. If turnout is light, I don't expect us to make any decisions but we can't continue to debate whether it's okay to "bypass the guidelines". We have to know what standing they have. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Thu May 17 00:59:50 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 16 May 2007 19:59:50 -0500 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179362197.2746.313.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> Message-ID: <1179363591.6254.47.camel@localhost.localdomain> On Wed, 2007-05-16 at 17:36 -0700, Toshio Kuratomi wrote: > On Wed, 2007-05-16 at 15:11 -0400, Brian Pepple wrote: > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > I think we need to discuss whether the Packaging Guidelines are only > Guidelines or if they're Rules. If the latter, whether we're willing to > take any actions to enforce them. If turnout is light, I don't expect > us to make any decisions but we can't continue to debate whether it's > okay to "bypass the guidelines". We have to know what standing they > have. This may be above FESCO's pay grade to decide. I suspect the Board needs to decide this. ~spot From wtogami at redhat.com Thu May 17 01:04:42 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 May 2007 21:04:42 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179362197.2746.313.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> Message-ID: <464BAA2A.4080101@redhat.com> Toshio Kuratomi wrote: > On Wed, 2007-05-16 at 15:11 -0400, Brian Pepple wrote: > >> You want something to be discussed? Send a note to the list in reply to >> this mail and I'll add it to the schedule (I can't promise we will get >> to it tomorrow, but we'll most likely will if we don't run out of time). >> You can also propose topics in the meeting while it is in the "Free >> discussion around Fedora" phase. > > I think we need to discuss whether the Packaging Guidelines are only > Guidelines or if they're Rules. If the latter, whether we're willing to > take any actions to enforce them. If turnout is light, I don't expect > us to make any decisions but we can't continue to debate whether it's > okay to "bypass the guidelines". We have to know what standing they > have. > My personal opinion... Guidelines should be VERY STRONG SUGGESTIONS. Any deviation from the guidelines should be rare, and better have a damned good reason, tracked someplace that is easy to find. In most cases deviations from guidelines are due to cases that are poorly or not defined in the guidelines. Such cases should be studied to see if the guidelines can be amended to define and control such cases in the future. In the end, FESCo should have the ability to overrule a deviation and force compliance in any individual case. Warren Togami wtogami at redhat.com From tibbs at math.uh.edu Thu May 17 01:10:11 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 May 2007 20:10:11 -0500 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <464BAA2A.4080101@redhat.com> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <464BAA2A.4080101@redhat.com> Message-ID: >>>>> "WT" == Warren Togami writes: WT> Guidelines should be VERY STRONG SUGGESTIONS. Any deviation from WT> the guidelines should be rare, and better have a damned good WT> reason, tracked someplace that is easy to find. The guidelines (especially the one in question) already have exception clauses. The packager needs to present their argument before the appropriate committee and if their argument is reasonable and persuasive they can be granted an exception. - J< From tcallawa at redhat.com Thu May 17 01:25:12 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 16 May 2007 20:25:12 -0500 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <464BAA2A.4080101@redhat.com> Message-ID: <1179365112.6254.53.camel@localhost.localdomain> On Wed, 2007-05-16 at 20:10 -0500, Jason L Tibbitts III wrote: > >>>>> "WT" == Warren Togami writes: > > WT> Guidelines should be VERY STRONG SUGGESTIONS. Any deviation from > WT> the guidelines should be rare, and better have a damned good > WT> reason, tracked someplace that is easy to find. > > The guidelines (especially the one in question) already have exception > clauses. The packager needs to present their argument before the > appropriate committee and if their argument is reasonable and > persuasive they can be granted an exception. I don't think we've ever denied an exception request. Not that very many have ever been made. ~spot From wtogami at redhat.com Thu May 17 02:12:08 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 May 2007 22:12:08 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179365112.6254.53.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <464BAA2A.4080101@redhat.com> <1179365112.6254.53.camel@localhost.localdomain> Message-ID: <464BB9F8.90105@redhat.com> Tom "spot" Callaway wrote: > On Wed, 2007-05-16 at 20:10 -0500, Jason L Tibbitts III wrote: >>>>>>> "WT" == Warren Togami writes: >> WT> Guidelines should be VERY STRONG SUGGESTIONS. Any deviation from >> WT> the guidelines should be rare, and better have a damned good >> WT> reason, tracked someplace that is easy to find. >> >> The guidelines (especially the one in question) already have exception >> clauses. The packager needs to present their argument before the >> appropriate committee and if their argument is reasonable and >> persuasive they can be granted an exception. > > I don't think we've ever denied an exception request. Not that very many > have ever been made. > Hmm.. on second thought this does sound pretty good. Guidelines as strict rules, and you have to request exceptions... Warren From katzj at redhat.com Thu May 17 03:12:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 16 May 2007 23:12:32 -0400 Subject: Update System: Not Rawhide In-Reply-To: <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> <200705161907.06342.jkeating@redhat.com> <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> Message-ID: <1179371552.5617.10.camel@aglarond.local> On Wed, 2007-05-16 at 17:02 -0700, Chris Weyl wrote: > On 5/16/07, Jesse Keating wrote: > > On Wednesday 16 May 2007 19:02:13 Chris Weyl wrote: > > > Can't we branch before freeze? Wouldn't that obviate the need for > > > freezing rawhide? > > > > I do believe the future plan is to let folks branch when they need to, since > > not everybody wants to have yet another branch to apply fixes to for the last > > month+ of a release. > > In such a scenario, would packages that branch prior to a mandated > "must branch by" date still find themselves frozen in devel? If so, > it wouldn't seem to help much... One would think we'd pursue this > sort of pre-freeze branching, as it would probably tend to get people > in the mindset of "hey, this isn't me noodling around in rawhide > anymore, but a package targeted for actual release". devel wouldn't be frozen; what collection the tree currently known as rawhide will follow, well.. that's a harder call. We get a lot of benefit by having rawhide match the upcoming release due to the large number of users testing the tree and shaking out problems. If rawhide diverged earlier, we'd see a substantial drop in the number of testers and thus the number of things found late in the game. It's definitely a discussion that's worth having once we get F7 wrapped up, although probably more on fedora-devel-list rather than here (so that more people can be involved) Jeremy From katzj at redhat.com Thu May 17 03:12:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 16 May 2007 23:12:32 -0400 Subject: Update System: Not Rawhide In-Reply-To: <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> <200705161907.06342.jkeating@redhat.com> <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> Message-ID: <1179371552.5617.10.camel@aglarond.local> On Wed, 2007-05-16 at 17:02 -0700, Chris Weyl wrote: > On 5/16/07, Jesse Keating wrote: > > On Wednesday 16 May 2007 19:02:13 Chris Weyl wrote: > > > Can't we branch before freeze? Wouldn't that obviate the need for > > > freezing rawhide? > > > > I do believe the future plan is to let folks branch when they need to, since > > not everybody wants to have yet another branch to apply fixes to for the last > > month+ of a release. > > In such a scenario, would packages that branch prior to a mandated > "must branch by" date still find themselves frozen in devel? If so, > it wouldn't seem to help much... One would think we'd pursue this > sort of pre-freeze branching, as it would probably tend to get people > in the mindset of "hey, this isn't me noodling around in rawhide > anymore, but a package targeted for actual release". devel wouldn't be frozen; what collection the tree currently known as rawhide will follow, well.. that's a harder call. We get a lot of benefit by having rawhide match the upcoming release due to the large number of users testing the tree and shaking out problems. If rawhide diverged earlier, we'd see a substantial drop in the number of testers and thus the number of things found late in the game. It's definitely a discussion that's worth having once we get F7 wrapped up, although probably more on fedora-devel-list rather than here (so that more people can be involved) Jeremy From tibbs at math.uh.edu Thu May 17 03:52:43 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 May 2007 22:52:43 -0500 Subject: Update System: Not Rawhide In-Reply-To: <1179371552.5617.10.camel@aglarond.local> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> <200705161907.06342.jkeating@redhat.com> <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> <1179371552.5617.10.camel@aglarond.local> Message-ID: >>>>> "JK" == Jeremy Katz writes: JK> If rawhide diverged earlier, we'd see a substantial drop in the JK> number of testers and thus the number of things found late in the JK> game. I've seen that claim multiple times, but I'm not sure I've ever seen any evidence to back it up. Even assuming that the claim is true, there's a need to balance those effects versus those of having the repo that's supposed to be stabilizing also be the one where all development has to happen. - J< From notting at redhat.com Thu May 17 03:59:42 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 16 May 2007 23:59:42 -0400 Subject: Update System: Not Rawhide In-Reply-To: References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> <200705161907.06342.jkeating@redhat.com> <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> <1179371552.5617.10.camel@aglarond.local> Message-ID: <20070517035942.GG18242@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > >>>>> "JK" == Jeremy Katz writes: > > JK> If rawhide diverged earlier, we'd see a substantial drop in the > JK> number of testers and thus the number of things found late in the > JK> game. > > I've seen that claim multiple times, but I'm not sure I've ever seen > any evidence to back it up. Even assuming that the claim is true, > there's a need to balance those effects versus those of having the > repo that's supposed to be stabilizing also be the one where all > development has to happen. How much testing is done by people who update to the latest rawhide and try things? With koji, packages are available through the interface if people want them. So we could set up builds for the next distribution that people could still get if they wanted, all while having rawhide for distribution testers pointing at the current in-development tree. Bill From dev at nigelj.com Thu May 17 04:05:02 2007 From: dev at nigelj.com (Nigel Jones) Date: Thu, 17 May 2007 16:05:02 +1200 (NZST) Subject: Update System: Not Rawhide In-Reply-To: References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> <200705161907.06342.jkeating@redhat.com> <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> <1179371552.5617.10.camel@aglarond.local> Message-ID: <12806.202.74.202.139.1179374702.squirrel@webmail.nigelj.com> >>>>>> "JK" == Jeremy Katz writes: > > JK> If rawhide diverged earlier, we'd see a substantial drop in the > JK> number of testers and thus the number of things found late in the > JK> game. > > I've seen that claim multiple times, but I'm not sure I've ever seen > any evidence to back it up. Even assuming that the claim is true, > there's a need to balance those effects versus those of having the > repo that's supposed to be stabilizing also be the one where all > development has to happen. > > - J< Personally, my opinion is roughly when the first components are frozen, devel is split, (i.e. F8/F9/whatever the next version ends up been), people interested in using 'the next great version' can then choose to use that repo, while those interested purely in keeping stuff up to date, do not have to wait for the next release to nearly happen. I think this can lead to an improved workflow (yes I realise it ends up into 4 maintained branches at any one time, and if a maintainer finds him/herself strapped for time to make changes in all 4 branches, then they should feel free to add co-maintainers. N.J. From rc040203 at freenet.de Thu May 17 04:52:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 06:52:20 +0200 Subject: Offering packages for co-maintenance or adoption In-Reply-To: <20070516202957.019722a1.bugs.michael@gmx.net> References: <1179301522.4735.630.camel@mccallum.corsepiu.local> <464AC07E.1060101@nigelj.com> <1179318150.4735.642.camel@mccallum.corsepiu.local> <20070516165250.3832c90e.bugs.michael@gmx.net> <1179334654.4735.767.camel@mccallum.corsepiu.local> <20070516202957.019722a1.bugs.michael@gmx.net> Message-ID: <1179377541.4735.805.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 20:29 +0200, Michael Schwendt wrote: > On Wed, 16 May 2007 18:57:33 +0200, Ralf Corsepius wrote: > > > > > http://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > > > > Look in the list archives (February 20th), the message > > > with the subject "Orphanizing the OrphanedPackages Wiki page") is the > > > announcement that the page is unmaintained. > > > > And the page had not be updated. I'd really appreciate some > > professionalism and some people exhibiting responsibility. > > Well, what update? Update the page to "current practice". Jesse Keating did so after I had complained. > A warning at the top that "mschwendt no longer > is subscribed to the page"? ;o) Nah, this remark wasn't addressed at you. It was addressed at those persons who have broken owners.list's handling. Ralf From jkeating at redhat.com Thu May 17 05:14:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 May 2007 01:14:12 -0400 Subject: Outage Notification - 2007-05-17 04:00 [UTC] In-Reply-To: <464B3EDB.2070709@redhat.com> References: <464B3EDB.2070709@redhat.com> Message-ID: <200705170114.13392.jkeating@redhat.com> On Wednesday 16 May 2007 13:26:51 Mike McGrath wrote: > There will be an outage starting at 2007-05-17 04:00 [UTC], which will last > approximately 1 hour. To convert UTC to your local time, use: > http://www.timeanddate.com/worldclock/converter.html > > Affected Services: > > Buildsystem > > Unaffected Services: > > Websites > CVS / Source Control > Database > DNS > Mail > Torrent > > > > Reason for Outage: > Upgrading Koji to a new version and moving koji store to new hardware. > This outage should be approximately 1 hour, maybe longer if the sync is > running slower then expected. Will be coordinating in #fedora-admin The > build system should either reject connections or queue connections during > this time. > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email to > track the status of this outage. > Current status: Koji software has been updated. We're still waiting for the final rsync to finish to move to new storage. The outage may wind up taking more than an hour, however we really need to get to this new storage so we'll keep things down until that is done. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Thu May 17 05:17:33 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 May 2007 00:17:33 -0500 Subject: Outage Notification - 2007-05-17 04:00 [UTC] In-Reply-To: <464B3EDB.2070709@redhat.com> References: <464B3EDB.2070709@redhat.com> Message-ID: <464BE56D.604@redhat.com> Mike McGrath wrote: > There will be an outage starting at 2007-05-17 04:00 [UTC], which will > last > approximately 1 hour. To convert UTC to your local time, use: > http://www.timeanddate.com/worldclock/converter.html An outage is as an outage does. This one is taking longer then we had planned for a few reasons. Stop by #fedora-admin to check on the status but we're going to see this one through till its done. I'll send a notification when that is. -Mike From rc040203 at freenet.de Thu May 17 05:17:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 07:17:53 +0200 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <464BAA2A.4080101@redhat.com> Message-ID: <1179379073.4735.808.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 20:10 -0500, Jason L Tibbitts III wrote: > >>>>> "WT" == Warren Togami writes: > > WT> Guidelines should be VERY STRONG SUGGESTIONS. Any deviation from > WT> the guidelines should be rare, and better have a damned good > WT> reason, tracked someplace that is easy to find. > > The guidelines (especially the one in question) already have exception > clauses. The packager needs to present their argument before the > appropriate committee and if their argument is reasonable and > persuasive they can be granted an exception. +1 Ralf From jspaleta at gmail.com Thu May 17 06:07:43 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 May 2007 22:07:43 -0800 Subject: Update System: Not Rawhide In-Reply-To: <12806.202.74.202.139.1179374702.squirrel@webmail.nigelj.com> References: <464B3E3B.9000105@redhat.com> <20070516174123.GD8430@nostromo.devel.redhat.com> <7dd7ab490705161602w549b02el9ca618fd8b4ed96c@mail.gmail.com> <200705161907.06342.jkeating@redhat.com> <7dd7ab490705161702ob4d7e2dudf337cf853ec8b80@mail.gmail.com> <1179371552.5617.10.camel@aglarond.local> <12806.202.74.202.139.1179374702.squirrel@webmail.nigelj.com> Message-ID: <604aa7910705162307s758dd358l6a22d4e967671506@mail.gmail.com> On 5/16/07, Nigel Jones wrote: > I think this can lead to an improved workflow (yes I realise it ends up > into 4 maintained branches at any one time, and if a maintainer finds > him/herself strapped for time to make changes in all 4 branches, then they > should feel free to add co-maintainers. Uhm you make it sound like co-maintainers are an infinite resource. I'm here to tell you that they aren't. Co-maintainers aren't pogs or AOL cds. If the workload increases for all maintainers, then you are effectively pulling manhours away from the available labor pool that could be used for wider co-maintainership activity. Do we have a reasonable way yet to add a co-maintainer on packages who isn't aren't already a primary maintainer on at least one package? I'd love to pull in people from outside the existing Fedora contributor space who know the software I act as a primary maintainer for and train them up to be competent package monkeys, giving them specific co-maintainership duties, without having them go through the standard sponsorship process through package submission. For the crap I maintain... I don't need other people who are reasonable good at maintaining Fedora packages. I need to build relationships with people who know how to grok the codebase inside the packages and get them hooked into the process of maintainership in Fedora space with me acting as the gatekeeper to ensure Fedora packaging policies are observed. As long as the same level of contributor sponsorship status is required for primary maintainers as well as co-maintainers..all we are doing is redistributing the available sponsored contributor labor force and not adding a new pool of labor. I am the package monkey, I've got that role pretty much covered. What I need are code monkeys (preferably of the genus upstreamum gurunish ) who can help me patch bugs on an as needed basis. Beyond that little rant, I don't see how an additional branching aids in workflow. You have to have some very specific and very agreed on doctrine on how the pre-release and development branches interact... and a ninja-grade QA process to shadow the pre-release branching... and universal respect for stabilization policy enforcement. Now I have high hopes for Will and the QA process, but policy enforcement is and will be a huge problem for what is essentially a volunteer managed software collection. Adding yet another branch meant for stabilization doesn't automatically prevent crap from breaking in an untimely manner. We don't have anything close to a demarcation of tiers in the software stack by which we can incrementally clamp down a stabilization policy. And even if we did, there isn't a real policy enforcement model in place to 'encourage' maintainers to stick to a structured stabilization process that 'discourages' significant changes in fundamental tiers of the software stack. And even if we did, structured stabilization processes take longer...longer than we actually have. Late breaking fixes going in to the stabilization tree will undoubtedly cause regressions that require additional fixes...just like you see in rawhide. We do not have the laborforce, the timescale, nor the centralized management enforcement mechanisms to make a dedicated controlled stabilization branch mean anything other than a version of rawhide that is on average harder to get changes pushed into than rawhide is. I'll tell you right now... even with the few packages I have... there's a snowball's chance in hell that I'd be able to keep up with updating into additional pre-release branches as well as development. And a bigger snowball's chance that I'd have spare cycles to take on additional co-maintainership duties beyond the packages that I am primary owner for. If there is a very early split for the next release, I will undoubtedly be forced to choose where i spend what time I have between updating devel,pre-release updating,reviewing new or god-forbid lingering merge reviews,and prepping my own new packaging. Someone is going to have to do a pretty damn good sales pitch to convince me that a pre-release branch is worth my time to update compared to rawhide. -jef"man i love my new postdoc... i'm writing python bindings over C code.. so I can work with the radar data with scipy and friends....specifically to avoid having to do the data analysis in IDL or matlab and watching money get burned on yet another per-seat software license just to draw pretty graphs of auto-correlation functions."spaleta From rc040203 at freenet.de Thu May 17 06:33:21 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 08:33:21 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070516200454.GB2890@free.fr> References: <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> Message-ID: <1179383601.4735.822.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 22:04 +0200, Patrice Dumas wrote: > On Tue, May 15, 2007 at 04:43:13PM -0700, Toshio Kuratomi wrote: > > > > Unless a guideline is marked as a "should" it is mandatory. If you > > disagree with something the guidelines say is a must, the proper thing > > to do is to get the guideline changed.[1]_ > > For the static libraries, I voiced my concerns on fedora-packaging, Ralf > responded without answering my arguments, I reresponded and nothing > happened after that. I repeatedly answered to your concerns. To reiterate: * I don't see any technical reason for inclusion of any static library in a distribution. Your primary argument "numerical programs" is a non-argument - You simply are in error. * Exceptions from this are not FPC's business, but are a political/management issue, which should be decided by a management entity. The guidelines reflect this notion by forcing packages to redirect such decisions to FESCo. Ralf From rc040203 at freenet.de Thu May 17 06:46:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 08:46:27 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179258710.20155.23.camel@localhost.localdomain> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> Message-ID: <1179384387.4735.827.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 15:51 -0400, Christopher Blizzard wrote: > I've been following this thread pretty casually. So here are my > thoughts: > 4. We want to make sure that there's _some_ comment about why an update > happens that end users might understand. a) This comment already is supposed to be in an rpm.spec's changelog. And similarly to "make clog", I don't see any reason why it can't automatically be derived from there. b) At least wrt. my packages, probably 90% of all "updates" are either addressing packaging issues or "trivial" upstream updates. I really don't see much reason why comments about them would be useful. Ralf From giallu at gmail.com Thu May 17 08:15:24 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 17 May 2007 10:15:24 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <1179320638.13214.31.camel@zod.rchland.ibm.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179320638.13214.31.camel@zod.rchland.ibm.com> Message-ID: On 5/16/07, Josh Boyer wrote: > On Wed, 2007-05-16 at 07:44 -0500, Josh Boyer wrote: > > > > > em8300-kmod: > > FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) > > em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop > > rel-eng knows about this one already. Ville is waiting on the final > kernel version to be decided so he can tag the appropriate module. Where can I find this info? it will be also needed for sysprof-kmod From mmcgrath at redhat.com Thu May 17 08:40:56 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 17 May 2007 03:40:56 -0500 Subject: Outage Notification - 2007-05-17 04:00 [UTC] In-Reply-To: <464BE56D.604@redhat.com> References: <464B3EDB.2070709@redhat.com> <464BE56D.604@redhat.com> Message-ID: <464C1518.5080706@redhat.com> Mike McGrath wrote: > Mike McGrath wrote: >> There will be an outage starting at 2007-05-17 04:00 [UTC], which >> will last >> approximately 1 hour. To convert UTC to your local time, use: >> http://www.timeanddate.com/worldclock/converter.html > > An outage is as an outage does. This one is taking longer then we had > planned for a few reasons. Stop by #fedora-admin to check on the > status but we're going to see this one through till its done. I'll > send a notification when that is. Outage Over. There were multiple changes with this outage so if anything seems out of place please contact us and let us know. Total outage time: roughly 4 hours. -Mike From jwboyer at jdub.homelinux.org Thu May 17 10:50:23 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 05:50:23 -0500 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179320638.13214.31.camel@zod.rchland.ibm.com> Message-ID: <1179399023.8746.28.camel@vader.jdub.homelinux.org> On Thu, 2007-05-17 at 10:15 +0200, Gianluca Sforna wrote: > On 5/16/07, Josh Boyer wrote: > > On Wed, 2007-05-16 at 07:44 -0500, Josh Boyer wrote: > > > > > > > > em8300-kmod: > > > FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) > > > em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop > > > > rel-eng knows about this one already. Ville is waiting on the final > > kernel version to be decided so he can tag the appropriate module. > > Where can I find this info? it will be also needed for sysprof-kmod It's not known yet. Which is why Ville is still waiting. josh From giallu at gmail.com Thu May 17 11:40:12 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 17 May 2007 13:40:12 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <1179399023.8746.28.camel@vader.jdub.homelinux.org> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179320638.13214.31.camel@zod.rchland.ibm.com> <1179399023.8746.28.camel@vader.jdub.homelinux.org> Message-ID: On 5/17/07, Josh Boyer wrote: > On Thu, 2007-05-17 at 10:15 +0200, Gianluca Sforna wrote: > > On 5/16/07, Josh Boyer wrote: > > > On Wed, 2007-05-16 at 07:44 -0500, Josh Boyer wrote: > > > > > > > > > > > em8300-kmod: > > > > FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) > > > > em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop > > > > > > rel-eng knows about this one already. Ville is waiting on the final > > > kernel version to be decided so he can tag the appropriate module. > > > > Where can I find this info? it will be also needed for sysprof-kmod > > It's not known yet. Which is why Ville is still waiting. mmm let me rephrase it (sorry for my english...) : whenever it will be decided, how am I supposed to be notified about it? In other words, will there be a "go!" signal somewhere, so I can rebuild the kmod in time for f7-final? From jonathan.underwood at gmail.com Thu May 17 11:50:40 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 17 May 2007 12:50:40 +0100 Subject: De-sucking the packaging documentation Message-ID: <645d17210705170450t2b274ec6u63b1b27ecdcb3b36@mail.gmail.com> Hello, The current state of documentation about the buildsystem, tagging, releases etc sucks. Noone is to blame, there's been a lot of churn with regard to building, tagging etc, and much of the pertinent documentation isn't easy to find, and isn't particularly accessible when you do find it. The nearest thing to helpful is Josh Boyer's FAQ, but that's only findable if you've been keeping up with this mailing list. I think there's a need for some concerted documentation writing needed to help packagers. I'm willing to help out with this, but I don't want to go blindly hacking away at things. So, do other people have thoughts on the best approach to this. Is anyone else interested in helping out? Jonathan. From jwboyer at jdub.homelinux.org Thu May 17 11:55:18 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 06:55:18 -0500 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179320638.13214.31.camel@zod.rchland.ibm.com> <1179399023.8746.28.camel@vader.jdub.homelinux.org> Message-ID: <1179402918.8746.34.camel@vader.jdub.homelinux.org> On Thu, 2007-05-17 at 13:40 +0200, Gianluca Sforna wrote: > On 5/17/07, Josh Boyer wrote: > > On Thu, 2007-05-17 at 10:15 +0200, Gianluca Sforna wrote: > > > On 5/16/07, Josh Boyer wrote: > > > > On Wed, 2007-05-16 at 07:44 -0500, Josh Boyer wrote: > > > > > > > > > > > > > > em8300-kmod: > > > > > FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) > > > > > em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop > > > > > > > > rel-eng knows about this one already. Ville is waiting on the final > > > > kernel version to be decided so he can tag the appropriate module. > > > > > > Where can I find this info? it will be also needed for sysprof-kmod > > > > It's not known yet. Which is why Ville is still waiting. > > mmm let me rephrase it (sorry for my english...) : whenever it will be > decided, how am I supposed to be notified about it? > In other words, will there be a "go!" signal somewhere, so I can > rebuild the kmod in time for f7-final? Ah. I'll try and bug DaveJ about it as we get closer and send (or have him send) something out once it's know. josh From Axel.Thimm at ATrpms.net Thu May 17 12:18:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 May 2007 14:18:36 +0200 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179362197.2746.313.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> Message-ID: <20070517121836.GC13287@neu.nirvana> On Wed, May 16, 2007 at 05:36:37PM -0700, Toshio Kuratomi wrote: > On Wed, 2007-05-16 at 15:11 -0400, Brian Pepple wrote: > > > You want something to be discussed? Send a note to the list in reply to > > this mail and I'll add it to the schedule (I can't promise we will get > > to it tomorrow, but we'll most likely will if we don't run out of time). > > You can also propose topics in the meeting while it is in the "Free > > discussion around Fedora" phase. > > I think we need to discuss whether the Packaging Guidelines are only > Guidelines or if they're Rules. If the latter, whether we're willing to > take any actions to enforce them. If turnout is light, I don't expect > us to make any decisions but we can't continue to debate whether it's > okay to "bypass the guidelines". We have to know what standing they > have. But note that many of the guidelines that have been drafted and passed through have done so by assuming they are not carved in stone immobilizing any (sane) deviation, e.g. that they are capturing best practices and are to _guide_ the packager. Otherwise we'd have to be far more careful and cover more corner cases to not start slipping packages into becoming violating ones. Of course some guildelines are more law than other guidelines. My suggestion is: Instead of making the guidelines law, just allow people (reviewers etc.) to report possible violations to some entity (fesco or a fesco born sig) that can either wave them though or declare them blockers. /me doesn't want to have to rewrite all of the guidelines with exceptions to allow the kernel package to be conforming. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From coldwell at redhat.com Thu May 17 12:31:11 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 17 May 2007 08:31:11 -0400 (EDT) Subject: De-sucking the packaging documentation In-Reply-To: <645d17210705170450t2b274ec6u63b1b27ecdcb3b36@mail.gmail.com> References: <645d17210705170450t2b274ec6u63b1b27ecdcb3b36@mail.gmail.com> Message-ID: On Thu, 17 May 2007, Jonathan Underwood wrote: > > The current state of documentation about the buildsystem, tagging, > releases etc sucks. +1 I think some of the blame should also be assigned to a rather ambitious set of goals for F7, i.e. doing the core/extras merge and EPEL at the same time as a release. Actually, does anyone else see any irony in the fact that Fedora is merging core+extras at the same time that RHEL is adding extras? > The nearest thing to helpful is Josh Boyer's FAQ, but that's only > findable if you've been keeping up with this mailing list. Where is it? > Is anyone else interested in helping out? I could be. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From jwboyer at jdub.homelinux.org Thu May 17 12:33:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 07:33:00 -0500 Subject: De-sucking the packaging documentation In-Reply-To: References: <645d17210705170450t2b274ec6u63b1b27ecdcb3b36@mail.gmail.com> Message-ID: <1179405180.8746.47.camel@vader.jdub.homelinux.org> On Thu, 2007-05-17 at 08:31 -0400, Chip Coldwell wrote: > On Thu, 17 May 2007, Jonathan Underwood wrote: > > > > > The current state of documentation about the buildsystem, tagging, > > releases etc sucks. > > +1 > > I think some of the blame should also be assigned to a rather > ambitious set of goals for F7, i.e. doing the core/extras merge and > EPEL at the same time as a release. Actually, does anyone else see > any irony in the fact that Fedora is merging core+extras at the same > time that RHEL is adding extras? I don't think that's the case at all. There are perhaps 2 or 3 people working on EPEL that overlap on the infrastructure side of things for Fedora. EPEL has no bearing here in the least. Ambitious goals, perhaps. EPEL, no. > > The nearest thing to helpful is Josh Boyer's FAQ, but that's only > > findable if you've been keeping up with this mailing list. > > Where is it? http://fedoraproject.org/wiki/JoshBoyer/MergeHOWTO josh From dev at nigelj.com Thu May 17 12:39:23 2007 From: dev at nigelj.com (Nigel Jones) Date: Fri, 18 May 2007 00:39:23 +1200 Subject: De-sucking the packaging documentation In-Reply-To: References: <645d17210705170450t2b274ec6u63b1b27ecdcb3b36@mail.gmail.com> Message-ID: <464C4CFB.5000902@nigelj.com> Chip Coldwell wrote: > On Thu, 17 May 2007, Jonathan Underwood wrote: > >> The current state of documentation about the buildsystem, tagging, >> releases etc sucks. > > +1 +1 > > I think some of the blame should also be assigned to a rather > ambitious set of goals for F7, i.e. doing the core/extras merge and > EPEL at the same time as a release. Actually, does anyone else see > any irony in the fact that Fedora is merging core+extras at the same > time that RHEL is adding extras? No, Fedora Core and Fedora Extras are just about always used together. EPEL is designed for items that are not maintained for RHEL but may be useful in an EL enviroment, like nagios, powerman or maybe even wine. I very much doubt we'd even see a RHEL+EPEL merge ;) > >> The nearest thing to helpful is Josh Boyer's FAQ, but that's only >> findable if you've been keeping up with this mailing list. > > Where is it? http://www.fedoraproject.org/wiki/JoshBoyer/MergeHOWTO N.J. From coldwell at redhat.com Thu May 17 12:52:49 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Thu, 17 May 2007 08:52:49 -0400 (EDT) Subject: De-sucking the packaging documentation In-Reply-To: <464C4CFB.5000902@nigelj.com> References: <645d17210705170450t2b274ec6u63b1b27ecdcb3b36@mail.gmail.com> <464C4CFB.5000902@nigelj.com> Message-ID: On Fri, 18 May 2007, Nigel Jones wrote: > > I very much doubt we'd even see a RHEL+EPEL merge ;) I'm going to keep a pointer to this message for later use ;->. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From katzj at redhat.com Thu May 17 14:30:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 17 May 2007 10:30:01 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179384387.4735.827.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <1179384387.4735.827.camel@mccallum.corsepiu.local> Message-ID: <1179412201.7682.50.camel@aglarond.local> On Thu, 2007-05-17 at 08:46 +0200, Ralf Corsepius wrote: > On Tue, 2007-05-15 at 15:51 -0400, Christopher Blizzard wrote: > > I've been following this thread pretty casually. So here are my > > thoughts: > > > 4. We want to make sure that there's _some_ comment about why an update > > happens that end users might understand. > a) This comment already is supposed to be in an rpm.spec's changelog. > > And similarly to "make clog", I don't see any reason why it can't > automatically be derived from there. I think everyone has been violently agreeing that we could take some steps to pre-populate with things like this. And we will. Just because it's not there at first doesn't mean it can't happen or won't ever happen or anything like that. There are just reality constraints around time that can't be changed which dictate when it will happen. > b) At least wrt. my packages, probably 90% of all "updates" are either > addressing packaging issues or "trivial" upstream updates. > > I really don't see much reason why comments about them would be useful. Highlight reasons that the update is useful! Obviously there's something that makes it so that you think it's useful, otherwise you wouldn't be doing the change. Fixing packaging issues that's going to solve a user visible problem, let it be known. On the other hand, if it's an "update" purely to fix aesthetic things in the spec file and that don't have any sort of functional impact, then maybe it's worth rethinking whether doing a build and push is worth it -- everyone who has the package installed will have to download the new one. That doesn't come for free. If it's a "trivial" upstream update, there still had to be a reason for upstream to do the release. As an upstream developer, one of the things I hate the most is doing releases of software just because there's so much involved. So there's always something that's compelling enough to be release-worthy... that's exactly what's worth communicating. I know that it's a little bit more to do to get a new package out, but so are a lot of the things which have changed over time with Fedora. I mean, I miss the days when I could just take a piece of software, throw together a package and voila, it ended up in rawhide. But the value in the review process is that it provides consistency and structure to ensure that everyone is doing things with the same frame of mind, etc and thus improving the quality of our packages so that our users get a better experience. The same idea is true here. All that said, there's definitely some room in most (if not all) of our current tools and workflows to improve them and make things easier. And it's something that I hope we can continue to look at and improve both to lower the bar for new contributors and make the lives of contributors who maintain 50+ packages. But we have to make sure that when we do so, we don't do it at the expense of our users. Jeremy From jkeating at redhat.com Thu May 17 14:37:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 May 2007 10:37:00 -0400 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <1179402918.8746.34.camel@vader.jdub.homelinux.org> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179402918.8746.34.camel@vader.jdub.homelinux.org> Message-ID: <200705171037.00562.jkeating@redhat.com> On Thursday 17 May 2007 07:55:18 Josh Boyer wrote: > Ah. ?I'll try and bug DaveJ about it as we get closer and send (or have > him send) something out once it's know. This is yet another reason why external kmods are such crap piles. Often times the kernel is the very last package to build, and when we "know" that it is good, is when we actually do the spins. We don't always have time to wait for N kernel mods to rebuild against it and get tagged. When the kmods were in a separate repo this was less of an issue, but now that everything is in the same repo it is far far more important of an issue and one that will hound us quite often, like with every kernel update. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Thu May 17 15:14:47 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 17 May 2007 16:14:47 +0100 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <200705171037.00562.jkeating@redhat.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179402918.8746.34.camel@vader.jdub.homelinux.org> <200705171037.00562.jkeating@redhat.com> Message-ID: <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> On 17/05/07, Jesse Keating wrote: > On Thursday 17 May 2007 07:55:18 Josh Boyer wrote: > > Ah. I'll try and bug DaveJ about it as we get closer and send (or have > > him send) something out once it's know. > > This is yet another reason why external kmods are such crap piles. Often > times the kernel is the very last package to build, and when we "know" that > it is good, is when we actually do the spins. We don't always have time to > wait for N kernel mods to rebuild against it and get tagged. When the kmods > were in a separate repo this was less of an issue, but now that everything is > in the same repo it is far far more important of an issue and one that will > hound us quite often, like with every kernel update. /me resists the urge to ask why Fedora doesn't move to using dkms for kernel modules. Yes, I know, Fedora is primarily a binary distribution. The packaging of kernel modules that Mathias has been doing for freshrpms with dkms is living testament to the ease of that approach though. Oh dear, I didn't resist the urge. From blizzard at redhat.com Thu May 17 15:18:34 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 17 May 2007 11:18:34 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179362197.2746.313.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> Message-ID: <1179415114.17014.7.camel@localhost.localdomain> On Wed, 2007-05-16 at 17:36 -0700, Toshio Kuratomi wrote: > > > I think we need to discuss whether the Packaging Guidelines are only > Guidelines or if they're Rules. If the latter, whether we're willing > to > take any actions to enforce them. If turnout is light, I don't expect > us to make any decisions but we can't continue to debate whether it's > okay to "bypass the guidelines". We have to know what standing they > have. Don't enable the rule police. Guidelines are "best form" but I don't think they need to be enforced to the level where it becomes crazy. Remember, we are here to enable developers so we need to be reasonable people. (An exception process? Come. On.) Honestly, I believe that this decision right here determines if we turn into structure for structure's sake or we turn into something that is open to developers. We need to stick to the middle ground here. Guidelines, not rules. --Chris From opensource at till.name Thu May 17 15:17:49 2007 From: opensource at till.name (Till Maas) Date: Thu, 17 May 2007 17:17:49 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <200705171037.00562.jkeating@redhat.com> <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> Message-ID: <200705171717.52795.opensource@till.name> On Do Mai 17 2007, Jonathan Underwood wrote: > distribution. The packaging of kernel modules that Mathias has been > doing for freshrpms with dkms is living testament to the ease of that > approach though. Oh dear, I didn't resist the urge. Yes, please allow dkms :-) Regards, Till From tcallawa at redhat.com Thu May 17 15:20:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 10:20:40 -0500 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179402918.8746.34.camel@vader.jdub.homelinux.org> <200705171037.00562.jkeating@redhat.com> <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> Message-ID: <1179415240.6254.62.camel@localhost.localdomain> On Thu, 2007-05-17 at 16:14 +0100, Jonathan Underwood wrote: > On 17/05/07, Jesse Keating wrote: > > On Thursday 17 May 2007 07:55:18 Josh Boyer wrote: > > > Ah. I'll try and bug DaveJ about it as we get closer and send (or have > > > him send) something out once it's know. > > > > This is yet another reason why external kmods are such crap piles. Often > > times the kernel is the very last package to build, and when we "know" that > > it is good, is when we actually do the spins. We don't always have time to > > wait for N kernel mods to rebuild against it and get tagged. When the kmods > > were in a separate repo this was less of an issue, but now that everything is > > in the same repo it is far far more important of an issue and one that will > > hound us quite often, like with every kernel update. > > /me resists the urge to ask why Fedora doesn't move to using dkms for > kernel modules. Yes, I know, Fedora is primarily a binary > distribution. The packaging of kernel modules that Mathias has been > doing for freshrpms with dkms is living testament to the ease of that > approach though. Oh dear, I didn't resist the urge. Because we will not assume our end users have full toolchains and kernel devel environments simply to get a driver installed. ~spot From tcallawa at redhat.com Thu May 17 15:31:23 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 10:31:23 -0500 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179415114.17014.7.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> Message-ID: <1179415883.6254.74.camel@localhost.localdomain> On Thu, 2007-05-17 at 11:18 -0400, Christopher Blizzard wrote: > On Wed, 2007-05-16 at 17:36 -0700, Toshio Kuratomi wrote: > > > > > > I think we need to discuss whether the Packaging Guidelines are only > > Guidelines or if they're Rules. If the latter, whether we're willing > > to > > take any actions to enforce them. If turnout is light, I don't expect > > us to make any decisions but we can't continue to debate whether it's > > okay to "bypass the guidelines". We have to know what standing they > > have. > > Don't enable the rule police. Guidelines are "best form" but I don't > think they need to be enforced to the level where it becomes crazy. > Remember, we are here to enable developers so we need to be reasonable > people. (An exception process? Come. On.) > > Honestly, I believe that this decision right here determines if we turn > into structure for structure's sake or we turn into something that is > open to developers. > > We need to stick to the middle ground here. Guidelines, not rules. I understand what you're saying, but we've got maintainers saying "I ignore the guidelines". This leads to bad packages. All we're really trying to do is make good packages. We've tried really hard to make guidelines that lead to good, clean, maintainable-long-after-you-are-dead packages. All we're asking (well, maybe all _I_ am asking) is that when people feel like they need to break one of the guidelines, they present their case and document that case in the spec file. I know that most of our packagers are smart folks, but LOTS of people learn how to write rpms from viewing spec file examples. When you're violating the guidelines for a valid corner case, and you just do it, someone else comes along and thinks its OK to violate the guidelines for their normal case. IMHO, none of the following are valid rationales: * "Always did it that way." * "I felt like it." * "Guidelines are dumb/silly/lame/broken." These are valid rationales: * "This package doesn't work without static libs." (The packager may not be able to fix the code to not use static libs, but by making the problem publicly known and internally documented, someone may come along and fix it for you. Yes, this has happened.) * "My package is doing something unique that falls outside of the guidelines." (When we see this, we make an exception for your package, and update the guidelines so that it is covered. If you never report it, we never know.) The Fedora Packaging Guidelines are living documents. Anyone with wiki access can submit a draft to add/change/alter/bend/mutilate them. The process is documented here: http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~spot From jonathan.underwood at gmail.com Thu May 17 15:43:21 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 17 May 2007 16:43:21 +0100 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <1179415240.6254.62.camel@localhost.localdomain> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179402918.8746.34.camel@vader.jdub.homelinux.org> <200705171037.00562.jkeating@redhat.com> <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> <1179415240.6254.62.camel@localhost.localdomain> Message-ID: <645d17210705170843l18cbe5f0h50b6d111bae97db1@mail.gmail.com> On 17/05/07, Tom spot Callaway wrote: > > > > /me resists the urge to ask why Fedora doesn't move to using dkms for > > kernel modules. Yes, I know, Fedora is primarily a binary > > distribution. The packaging of kernel modules that Mathias has been > > doing for freshrpms with dkms is living testament to the ease of that > > approach though. Oh dear, I didn't resist the urge. > > Because we will not assume our end users have full toolchains and kernel > devel environments simply to get a driver installed. Yes I realize.. Fedora isn't gentoo... hence i was resisting the urge. :) From blizzard at redhat.com Thu May 17 15:49:09 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 17 May 2007 11:49:09 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179415883.6254.74.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> Message-ID: <1179416949.17014.16.camel@localhost.localdomain> On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > > All we're really trying to do is make good packages. We've tried > really > hard to make guidelines that lead to good, clean, > maintainable-long-after-you-are-dead packages. > I hear what you are saying and I understand. What I'm saying is that there's a fine line between making good packages and going over the edge. So in your example, documenting is good. But if you end up with an exception process? I think that probably crosses the line. Dispute resolution, maybe. But I just worry that we're going somewhere we don't want to be. Not sure how to properly put this into words. --Chris From rc040203 at freenet.de Thu May 17 15:50:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 17:50:53 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705161608.45793.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <200705161129.20554.jkeating@redhat.com> <1179334012.4735.759.camel@mccallum.corsepiu.local> <200705161608.45793.jkeating@redhat.com> Message-ID: <1179417054.4735.843.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 16:08 -0400, Jesse Keating wrote: > On Wednesday 16 May 2007 12:46:51 Ralf Corsepius wrote: > > How to? URL? > > As I said before, the documentation doesn't quite exist. As others have > stated, the author is currently taking exams at college and that has a > slightly higher priority. Though I can relate to this from an individual's position, from a "user's" POV, this isn't necessarily professional. > Patience is a valueable virtue. Yes, may-be you better should have followed your advise yourself, instead of having prematurely deployed this (At least IMO: immature) works? Ralf From jkeating at redhat.com Thu May 17 15:53:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 May 2007 11:53:05 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179417054.4735.843.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <200705161608.45793.jkeating@redhat.com> <1179417054.4735.843.camel@mccallum.corsepiu.local> Message-ID: <200705171153.05559.jkeating@redhat.com> On Thursday 17 May 2007 11:50:53 Ralf Corsepius wrote: > > ? Patience is a valueable virtue. > > Yes, may-be you better should have followed your advise yourself, > instead of having prematurely deployed this (At least IMO: immature) > works? If we waited for everything to be perfect and to be fully documented and buy-in from every developer/user, we'd never get anything done. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu May 17 15:54:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 10:54:27 -0500 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179416949.17014.16.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> Message-ID: <1179417267.6254.79.camel@localhost.localdomain> On Thu, 2007-05-17 at 11:49 -0400, Christopher Blizzard wrote: > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > > > > All we're really trying to do is make good packages. We've tried > > really > > hard to make guidelines that lead to good, clean, > > maintainable-long-after-you-are-dead packages. > > > > I hear what you are saying and I understand. What I'm saying is that > there's a fine line between making good packages and going over the > edge. So in your example, documenting is good. But if you end up with > an exception process? I think that probably crosses the line. Dispute > resolution, maybe. But I just worry that we're going somewhere we don't > want to be. Not sure how to properly put this into words. What would you suggest we do in response to package maintainers saying "I ignore the guidelines"? How are we to be expected to keep the guidelines current and updated without being informed that some packages don't conform to them? I see the exception process as a necessary evil, and everytime it is invoked, we update the guidelines so that exception is not necessary. ~spot From pjones at redhat.com Thu May 17 15:56:36 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 11:56:36 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179416949.17014.16.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> Message-ID: <464C7B34.7020002@redhat.com> Christopher Blizzard wrote: > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: >> All we're really trying to do is make good packages. We've tried >> really >> hard to make guidelines that lead to good, clean, >> maintainable-long-after-you-are-dead packages. >> > > I hear what you are saying and I understand. What I'm saying is that > there's a fine line between making good packages and going over the > edge. So in your example, documenting is good. But if you end up with > an exception process? I think that probably crosses the line. Dispute > resolution, maybe. But I just worry that we're going somewhere we don't > want to be. Not sure how to properly put this into words. I'm totally in agreement that an exception process isn't somewhere we want to go. Arbitration when there's a dispute causes less impedance to actually getting things done, while still achieving the same goals. -- Peter From tcallawa at redhat.com Thu May 17 16:01:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 11:01:48 -0500 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <464C7B34.7020002@redhat.com> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> Message-ID: <1179417708.6254.81.camel@localhost.localdomain> On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > Christopher Blizzard wrote: > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > >> All we're really trying to do is make good packages. We've tried > >> really > >> hard to make guidelines that lead to good, clean, > >> maintainable-long-after-you-are-dead packages. > >> > > > > I hear what you are saying and I understand. What I'm saying is that > > there's a fine line between making good packages and going over the > > edge. So in your example, documenting is good. But if you end up with > > an exception process? I think that probably crosses the line. Dispute > > resolution, maybe. But I just worry that we're going somewhere we don't > > want to be. Not sure how to properly put this into words. > > I'm totally in agreement that an exception process isn't somewhere we > want to go. Arbitration when there's a dispute causes less impedance to > actually getting things done, while still achieving the same goals. But we're not even aware that there is a dispute, when people just decide not to follow the guidelines. There is no "Packaging QA" group, constantly auditing spec files. ~spot From blizzard at redhat.com Thu May 17 16:05:33 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 17 May 2007 12:05:33 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <464C7B34.7020002@redhat.com> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> Message-ID: <1179417934.17604.0.camel@localhost.localdomain> On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > Christopher Blizzard wrote: > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > >> All we're really trying to do is make good packages. We've tried > >> really > >> hard to make guidelines that lead to good, clean, > >> maintainable-long-after-you-are-dead packages. > >> > > > > I hear what you are saying and I understand. What I'm saying is that > > there's a fine line between making good packages and going over the > > edge. So in your example, documenting is good. But if you end up with > > an exception process? I think that probably crosses the line. Dispute > > resolution, maybe. But I just worry that we're going somewhere we don't > > want to be. Not sure how to properly put this into words. > > I'm totally in agreement that an exception process isn't somewhere we > want to go. Arbitration when there's a dispute causes less impedance to > actually getting things done, while still achieving the same goals. > +1 --Chris From blizzard at redhat.com Thu May 17 16:12:18 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 17 May 2007 12:12:18 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179417267.6254.79.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <1179417267.6254.79.camel@localhost.localdomain> Message-ID: <1179418338.17604.3.camel@localhost.localdomain> On Thu, 2007-05-17 at 10:54 -0500, Tom "spot" Callaway wrote: > > > What would you suggest we do in response to package maintainers saying > "I ignore the guidelines"? What evils are you trying to prevent? I agree if someone is being a jackass and not doing anything to even try to follow the guidelines, that's one thing. But missing a few odds and ends here and there, is that a big deal? Maybe we need some kind of "no asshole" rule for the guidelines? Turn this around: what incentives can we create to bring about better packaging as opposed to having something punitive like an exception process? --Chris From rc040203 at freenet.de Thu May 17 16:22:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 18:22:32 +0200 Subject: Updates System In-Reply-To: <464B3BD0.2010106@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <46494B13.1070500@hhs.nl> <200705151016.27873.jkeating@redhat.com> <20070515150020.GE2815@free.fr> <1179245466.1459.21.camel@metroid.rdu.redhat.com> <1179246660.4735.548.camel@mccallum.corsepiu.local> <1179249933.1459.35.camel@metroid.rdu.redhat.com> <1179287703.4735.589.camel@mccallum.corsepiu.local> <464A894A.3050308@redhat.com> <1179299948.4735.622.camel@mccallum.corsepiu.local> <464AB4A7.6040209@hhs.nl> <464B3BD0.2010106@redhat.com> Message-ID: <1179418953.4735.852.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 13:13 -0400, Warren Togami wrote: > Please reserve judgment until you actually see the system in action? The system already is in action - That's what all this is about. Ralf From bpepple at fedoraproject.org Thu May 17 16:22:57 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 17 May 2007 12:22:57 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <464C7B34.7020002@redhat.com> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> Message-ID: <1179418977.5843.6.camel@lincoln> On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > Christopher Blizzard wrote: > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > >> All we're really trying to do is make good packages. We've tried > >> really > >> hard to make guidelines that lead to good, clean, > >> maintainable-long-after-you-are-dead packages. > >> > > > > I hear what you are saying and I understand. What I'm saying is that > > there's a fine line between making good packages and going over the > > edge. So in your example, documenting is good. But if you end up with > > an exception process? I think that probably crosses the line. Dispute > > resolution, maybe. But I just worry that we're going somewhere we don't > > want to be. Not sure how to properly put this into words. > > I'm totally in agreement that an exception process isn't somewhere we > want to go. Arbitration when there's a dispute causes less impedance to > actually getting things done, while still achieving the same goals. How would you suggest we deal with maintainers that outright say they choose to ignore the packaging guidelines? /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Thu May 17 16:34:38 2007 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 17 May 2007 12:34:38 -0400 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179417708.6254.81.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> <1179417708.6254.81.camel@localhost.localdomain> Message-ID: <20070517163437.GD18892@psilocybe.teonanacatl.org> Tom spot Callaway wrote: > But we're not even aware that there is a dispute, when people just > decide not to follow the guidelines. There is no "Packaging QA" > group, constantly auditing spec files. Wouldn't that be something that a reviewer could bring up? Say I review a package with static libs and the submitter says "I don't care about the guidelines, I'm packaging them anyway for $reason." ($reason may be >= 0). If I can't persuade the submitter to change their view or at least document the reasoning, I can simply not approve the package. Then it doesn't get in at all (unless some other reviewer chooses to ignore the guidelines as well). I can also bring it up here and then it'll be in the eyes of other maintainers. It may end up being one of those corner cases that lead to clearer guidelines. Or maybe it will just lead to others noting that the submitter should use better reasoning. (Or maybe it will just lead to a never-ending debate. ;) If no one even notices that the guidelines aren't being followed by a package, then the problem might not be such a problem at all. There are a lot of other things that rank higher on the priority list, I'm sure. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Many questions are unanswerable. Many answers are questionable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu May 17 16:42:58 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 May 2007 18:42:58 +0200 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179417708.6254.81.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> <1179417708.6254.81.camel@localhost.localdomain> Message-ID: <20070517164258.GA25203@neu.nirvana> On Thu, May 17, 2007 at 11:01:48AM -0500, Tom spot Callaway wrote: > On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > > Christopher Blizzard wrote: > > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > > >> All we're really trying to do is make good packages. We've tried > > >> really > > >> hard to make guidelines that lead to good, clean, > > >> maintainable-long-after-you-are-dead packages. > > >> > > > > > > I hear what you are saying and I understand. What I'm saying is that > > > there's a fine line between making good packages and going over the > > > edge. So in your example, documenting is good. But if you end up with > > > an exception process? I think that probably crosses the line. Dispute > > > resolution, maybe. But I just worry that we're going somewhere we don't > > > want to be. Not sure how to properly put this into words. > > > > I'm totally in agreement that an exception process isn't somewhere we > > want to go. Arbitration when there's a dispute causes less impedance to > > actually getting things done, while still achieving the same goals. > > But we're not even aware that there is a dispute, when people just > decide not to follow the guidelines. There is no "Packaging QA" group, > constantly auditing spec files. This would still be the same issue if guidelines would tunr into laws with exception policies. "If no one sees the crime, there was no crime." This thread seems to have been spawn by some explicit example of a packager consciously violating the guidelines. But some of us don't know what the example is. Could you post in some URL? Maybe the issue is not solved by turning guidelines into stone, but by something else. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu May 17 16:47:08 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 18:47:08 +0200 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179415114.17014.7.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> Message-ID: <464C870C.9010103@leemhuis.info> On 17.05.2007 17:18, Christopher Blizzard wrote: > On Wed, 2007-05-16 at 17:36 -0700, Toshio Kuratomi wrote: >> I think we need to discuss whether the Packaging Guidelines are only >> Guidelines or if they're Rules. If the latter, whether we're willing >> to >> take any actions to enforce them. If turnout is light, I don't expect >> us to make any decisions but we can't continue to debate whether it's >> okay to "bypass the guidelines". We have to know what standing they >> have. > Don't enable the rule police. Guidelines are "best form" but I don't > think they need to be enforced to the level where it becomes crazy. Maybe not enforced -- but I'd like to see a group that *reminds* contributors about the guidelines if the spec files containn stuff that's not in line with the guidelines. Even in my own spec files I sometimes in the past found odd stuff that is not in line with the guidelines. Often the reasons for that is quite simple: details in the guidelines changed over time and I forgot to adjust the spec file as I simply was not aware that I had stuff in my spec files that needed adjustments. So especially when guidelines change it IMHO would be really helpful if someone or some group could (with grep or other tools) look over the spec files in the devel tree and mail people if something that should be changed turns up. Just my 2 cent. CU knurd From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu May 17 16:48:53 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 17 May 2007 18:48:53 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <645d17210705170843l18cbe5f0h50b6d111bae97db1@mail.gmail.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179402918.8746.34.camel@vader.jdub.homelinux.org> <200705171037.00562.jkeating@redhat.com> <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> <1179415240.6254.62.camel@localhost.localdomain> <645d17210705170843l18cbe5f0h50b6d111bae97db1@mail.gmail.com> Message-ID: <20070517184853.5ea29c0d@python3.es.egwn.lan> Jonathan Underwood wrote : > On 17/05/07, Tom spot Callaway wrote: > > > > > > /me resists the urge to ask why Fedora doesn't move to using dkms for > > > kernel modules. Yes, I know, Fedora is primarily a binary > > > distribution. The packaging of kernel modules that Mathias has been > > > doing for freshrpms with dkms is living testament to the ease of that > > > approach though. Oh dear, I didn't resist the urge. > > > > Because we will not assume our end users have full toolchains and kernel > > devel environments simply to get a driver installed. > > Yes I realize.. Fedora isn't gentoo... hence i was resisting the urge. :) Yet dkms is currently the best way to distribute kernel module packages for lazy packagers like me :-D And (most of the time), users aren't pending for a 3rd party repository update in order to be able to update to the latest errata kernel, which is a good thing, and because of this many are willing to sacrifice the loss of disk space from gcc and kernel-devel that it implies. There's (still) no solution sticking out as "best" for now :-/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 2.24 1.66 0.96 From fedora at leemhuis.info Thu May 17 16:57:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 18:57:51 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <1179402918.8746.34.camel@vader.jdub.homelinux.org> <200705171037.00562.jkeating@redhat.com> <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> Message-ID: <464C898F.8030005@leemhuis.info> On 17.05.2007 17:14, Jonathan Underwood wrote: > On 17/05/07, Jesse Keating wrote: >> On Thursday 17 May 2007 07:55:18 Josh Boyer wrote: >>> Ah. I'll try and bug DaveJ about it as we get closer and send (or have >>> him send) something out once it's know. >> This is yet another reason why external kmods are such crap piles. Often >> times the kernel is the very last package to build, and when we "know" that >> it is good, is when we actually do the spins. We don't always have time to >> wait for N kernel mods to rebuild against it and get tagged. When the kmods >> were in a separate repo this was less of an issue, but now that everything is >> in the same repo it is far far more important of an issue and one that will >> hound us quite often, like with every kernel update. > /me resists the urge to ask why Fedora doesn't move to using dkms for > kernel modules. Yes, I know, Fedora is primarily a binary > distribution. The packaging of kernel modules that Mathias has been > doing for freshrpms with dkms is living testament to the ease of that > approach though. Oh dear, I didn't resist the urge. In addition to what spot said: On the last FUDCon we discussed kernel module packaging with some people. The outcome roughly was to work on a new kernel module packaging standard solves both problems: create pre-compiled kernel-module packages that can be put in a repo for users to install; in addition create a dkms/dkms-like solution as rpm in the repo that users *can* install that will to get their modules rebuild for the current kernel (on boot?) *if* it's not available . I hope to find time after F7 is out to work on this. Ohh, further: there is certain resistance from some important folks to include kernel module packages in Fedora. Those people have some points, especially now that Core and Extras are merged. Thus I think we should create a separate repo in the scop of the Fedora projects to include kmods. Even more work (but I wrote something up already for that) :-/ CU thl From a.badger at gmail.com Thu May 17 16:59:35 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 17 May 2007 09:59:35 -0700 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <20070517164258.GA25203@neu.nirvana> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> <1179417708.6254.81.camel@localhost.localdomain> <20070517164258.GA25203@neu.nirvana> Message-ID: <1179421175.26613.3.camel@localhost.localdomain> On Thu, 2007-05-17 at 18:42 +0200, Axel Thimm wrote: > On Thu, May 17, 2007 at 11:01:48AM -0500, Tom spot Callaway wrote: > > On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > > > Christopher Blizzard wrote: > > > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > > > >> All we're really trying to do is make good packages. We've tried > > > >> really > > > >> hard to make guidelines that lead to good, clean, > > > >> maintainable-long-after-you-are-dead packages. > > > >> > > > > > > > > I hear what you are saying and I understand. What I'm saying is that > > > > there's a fine line between making good packages and going over the > > > > edge. So in your example, documenting is good. But if you end up with > > > > an exception process? I think that probably crosses the line. Dispute > > > > resolution, maybe. But I just worry that we're going somewhere we don't > > > > want to be. Not sure how to properly put this into words. > > > > > > I'm totally in agreement that an exception process isn't somewhere we > > > want to go. Arbitration when there's a dispute causes less impedance to > > > actually getting things done, while still achieving the same goals. > > > > But we're not even aware that there is a dispute, when people just > > decide not to follow the guidelines. There is no "Packaging QA" group, > > constantly auditing spec files. > > This would still be the same issue if guidelines would tunr into laws > with exception policies. "If no one sees the crime, there was no > crime." > > This thread seems to have been spawn by some explicit example of a > packager consciously violating the guidelines. But some of us don't > know what the example is. Could you post in some URL? Maybe the issue > is not solved by turning guidelines into stone, but by something else. Top of thread: https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00351.html Where it starts to get "interesting": https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00459.html -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Thu May 17 17:15:09 2007 From: opensource at till.name (Till Maas) Date: Thu, 17 May 2007 19:15:09 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <464C898F.8030005@leemhuis.info> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> <464C898F.8030005@leemhuis.info> Message-ID: <200705171915.12675.opensource@till.name> On Do Mai 17 2007, Thorsten Leemhuis wrote: > In addition to what spot said: On the last FUDCon we discussed kernel > module packaging with some people. The outcome roughly was to work on a > new kernel module packaging standard solves both problems: create > pre-compiled kernel-module packages that can be put in a repo for users > to install; in addition create a dkms/dkms-like solution as rpm in the > repo that users *can* install that will to get their modules rebuild for > the current kernel (on boot?) *if* it's not available . With a simple patch to dkms (don't know, whether or not it is required), that makes dkms only compile a new module, when there is none installed, this is already possible. Regards, Till From rc040203 at freenet.de Thu May 17 17:16:43 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 19:16:43 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705171153.05559.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <200705161608.45793.jkeating@redhat.com> <1179417054.4735.843.camel@mccallum.corsepiu.local> <200705171153.05559.jkeating@redhat.com> Message-ID: <1179422203.4735.861.camel@mccallum.corsepiu.local> On Thu, 2007-05-17 at 11:53 -0400, Jesse Keating wrote: > On Thursday 17 May 2007 11:50:53 Ralf Corsepius wrote: > > > Patience is a valueable virtue. > > > > Yes, may-be you better should have followed your advise yourself, > > instead of having prematurely deployed this (At least IMO: immature) > > works? > > If we waited for everything to be perfect and to be fully documented and > buy-in from every developer/user, we'd never get anything done. Well, you have prematurely deployed an immature product while the service personnel is non-reachable. In the commercial world you'd probably be sued for this. Ralf From jkeating at redhat.com Thu May 17 17:20:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 May 2007 13:20:09 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179422203.4735.861.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <200705171153.05559.jkeating@redhat.com> <1179422203.4735.861.camel@mccallum.corsepiu.local> Message-ID: <200705171320.09402.jkeating@redhat.com> On Thursday 17 May 2007 13:16:43 Ralf Corsepius wrote: > Well, you have prematurely deployed an immature product while the > service personnel is non-reachable. In the commercial world you'd > probably be sued for this. Ralf, where do you see Bodhi deployed? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alan at redhat.com Thu May 17 17:24:23 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 17 May 2007 13:24:23 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179422203.4735.861.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <200705161608.45793.jkeating@redhat.com> <1179417054.4735.843.camel@mccallum.corsepiu.local> <200705171153.05559.jkeating@redhat.com> <1179422203.4735.861.camel@mccallum.corsepiu.local> Message-ID: <20070517172423.GA17239@devserv.devel.redhat.com> On Thu, May 17, 2007 at 07:16:43PM +0200, Ralf Corsepius wrote: > > If we waited for everything to be perfect and to be fully documented and > > buy-in from every developer/user, we'd never get anything done. > > Well, you have prematurely deployed an immature product while the > service personnel is non-reachable. In the commercial world you'd > probably be sued for this. No because the shrinkwrap license (or page 314 of the 'standard terms and conditions') would no doubt exclude everything conceivable and a few more as well 8) From fedora at leemhuis.info Thu May 17 17:37:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 17 May 2007 19:37:22 +0200 Subject: 5/16/2007 Broken upgrade paths in F7 In-Reply-To: <200705171915.12675.opensource@till.name> References: <1179319488.13214.21.camel@zod.rchland.ibm.com> <645d17210705170814v6cc7dftba1948288349c715@mail.gmail.com> <464C898F.8030005@leemhuis.info> <200705171915.12675.opensource@till.name> Message-ID: <464C92D2.9030509@leemhuis.info> On 17.05.2007 19:15, Till Maas wrote: > On Do Mai 17 2007, Thorsten Leemhuis wrote: > >> In addition to what spot said: On the last FUDCon we discussed kernel >> module packaging with some people. The outcome roughly was to work on a >> new kernel module packaging standard solves both problems: create >> pre-compiled kernel-module packages that can be put in a repo for users >> to install; in addition create a dkms/dkms-like solution as rpm in the >> repo that users *can* install that will to get their modules rebuild for >> the current kernel (on boot?) *if* it's not available . > > With a simple patch to dkms (don't know, whether or not it is required), that > makes dkms only compile a new module, when there is none installed, this is > already possible. We don't want to maintain two codepaths, as that complicates maintenance and often results in bugs in one of them. Thus we IMHO should either use dkms within the buildsys to build the binary and the kernel-specific dkms rpms, or create a spec file that can be used in the buildsys as well as by dkms or a dkms like solution to create proper rpms on the user side. CU thl From pjones at redhat.com Thu May 17 17:40:10 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 13:40:10 -0400 Subject: An alternate proposal to answer the guidelines question. Message-ID: <464C937A.9010403@redhat.com> We were talking about this on #fedora-meeting, and I was asked to write up my answer to the question of how to handle violations of the packaging guidelines. It seems to me that the fundamental question is: what do I do when I find a packaging problem? The answer should be: 1) Contact the maintainer about it. Start by filing a bug, work from there. Be reasonable. 2) if the maintainer doesn't respond, or won't fix it and can't satisfy you with any good reasons why not, then send a note to FESCO. Conversely, if you're a maintainer and somebody won't listen to reason about when there is a good reason not to change something, contact FESCO. 3) when FESCO is notified of a problem, they appoint somebody who they trust to do the right thing to arbitrate the dispute. The arbitrator has the right to decide right and wrong here. 4) do what the arbitrator says. 5) if a maintainer still doesn't fix a package, the arbitrator lets FESCO know that we need to start the orphan package process. -- Peter From jkeating at redhat.com Thu May 17 17:45:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 May 2007 13:45:35 -0400 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C937A.9010403@redhat.com> References: <464C937A.9010403@redhat.com> Message-ID: <200705171345.35986.jkeating@redhat.com> On Thursday 17 May 2007 13:40:10 Peter Jones wrote: > It seems to me that the fundamental question is: what do I do when I > find a packaging problem? > > The answer should be: > > 1) Contact the maintainer about it. ?Start by filing a bug, work from > there. ?Be reasonable. > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > you with any good reasons why not, then send a note to FESCO. > Conversely, if you're a maintainer and somebody won't listen to reason > about when there is a good reason not to change something, contact FESCO. > 3) when FESCO is notified of a problem, they appoint somebody who they > trust to do the right thing to arbitrate the dispute. ?The arbitrator > has the right to decide right and wrong here. > 4) do what the arbitrator says. > 5) if a maintainer still doesn't fix a package, the arbitrator lets > FESCO know that we need to start the orphan package process. +1 -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Thu May 17 18:02:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 20:02:14 +0200 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C937A.9010403@redhat.com> References: <464C937A.9010403@redhat.com> Message-ID: <1179424934.4735.866.camel@mccallum.corsepiu.local> On Thu, 2007-05-17 at 13:40 -0400, Peter Jones wrote: > We were talking about this on #fedora-meeting, and I was asked to write > up my answer to the question of how to handle violations of the > packaging guidelines. > > It seems to me that the fundamental question is: what do I do when I > find a packaging problem? > > The answer should be: > > 1) Contact the maintainer about it. Start by filing a bug, work from > there. Be reasonable. > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > you with any good reasons why not, then send a note to FESCO. > Conversely, if you're a maintainer and somebody won't listen to reason > about when there is a good reason not to change something, contact FESCO. > 3) when FESCO is notified of a problem, they appoint somebody who they > trust to do the right thing to arbitrate the dispute. The arbitrator > has the right to decide right and wrong here. > 4) do what the arbitrator says. > 5) if a maintainer still doesn't fix a package, the arbitrator lets > FESCO know that we need to start the orphan package process. +1 Ralf From j.w.r.degoede at hhs.nl Thu May 17 18:18:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 17 May 2007 20:18:57 +0200 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C937A.9010403@redhat.com> References: <464C937A.9010403@redhat.com> Message-ID: <464C9C91.3080801@hhs.nl> Peter Jones wrote: > We were talking about this on #fedora-meeting, and I was asked to write > up my answer to the question of how to handle violations of the > packaging guidelines. > > It seems to me that the fundamental question is: what do I do when I > find a packaging problem? > > The answer should be: > > 1) Contact the maintainer about it. Start by filing a bug, work from > there. Be reasonable. > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > you with any good reasons why not, then send a note to FESCO. > Conversely, if you're a maintainer and somebody won't listen to reason > about when there is a good reason not to change something, contact FESCO. > 3) when FESCO is notified of a problem, they appoint somebody who they > trust to do the right thing to arbitrate the dispute. The arbitrator > has the right to decide right and wrong here. > 4) do what the arbitrator says. > 5) if a maintainer still doesn't fix a package, the arbitrator lets > FESCO know that we need to start the orphan package process. > In general this sounds reasonable, I especially like how this procedure normally shouldn't come into play, but only becomes active under exceptional circumstances. However the FESco apoints an arbitrator part wories me, the maintainer should have a say in this too. There are some people in this community who (unfortunately) mix about as well as fire and water. Regards, Hans From a.badger at gmail.com Thu May 17 18:05:34 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 17 May 2007 11:05:34 -0700 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <200705171345.35986.jkeating@redhat.com> References: <464C937A.9010403@redhat.com> <200705171345.35986.jkeating@redhat.com> Message-ID: <1179425134.26613.6.camel@localhost.localdomain> On Thu, 2007-05-17 at 13:45 -0400, Jesse Keating wrote: > On Thursday 17 May 2007 13:40:10 Peter Jones wrote: > > It seems to me that the fundamental question is: what do I do when I > > find a packaging problem? > > > > The answer should be: > > > > 1) Contact the maintainer about it. Start by filing a bug, work from > > there. Be reasonable. > > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > > you with any good reasons why not, then send a note to FESCO. > > Conversely, if you're a maintainer and somebody won't listen to reason > > about when there is a good reason not to change something, contact FESCO. > > 3) when FESCO is notified of a problem, they appoint somebody who they > > trust to do the right thing to arbitrate the dispute. The arbitrator > > has the right to decide right and wrong here. > > 4) do what the arbitrator says. > > 5) if a maintainer still doesn't fix a package, the arbitrator lets > > FESCO know that we need to start the orphan package process. > > +1 +1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Thu May 17 18:07:43 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 13:07:43 -0500 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C9C91.3080801@hhs.nl> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> Message-ID: <1179425263.9870.1.camel@zod.rchland.ibm.com> On Thu, 2007-05-17 at 20:18 +0200, Hans de Goede wrote: > Peter Jones wrote: > > We were talking about this on #fedora-meeting, and I was asked to write > > up my answer to the question of how to handle violations of the > > packaging guidelines. > > > > It seems to me that the fundamental question is: what do I do when I > > find a packaging problem? > > > > The answer should be: > > > > 1) Contact the maintainer about it. Start by filing a bug, work from > > there. Be reasonable. > > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > > you with any good reasons why not, then send a note to FESCO. > > Conversely, if you're a maintainer and somebody won't listen to reason > > about when there is a good reason not to change something, contact FESCO. > > 3) when FESCO is notified of a problem, they appoint somebody who they > > trust to do the right thing to arbitrate the dispute. The arbitrator > > has the right to decide right and wrong here. > > 4) do what the arbitrator says. > > 5) if a maintainer still doesn't fix a package, the arbitrator lets > > FESCO know that we need to start the orphan package process. > > > > In general this sounds reasonable, I especially like how this procedure > normally shouldn't come into play, but only becomes active under exceptional > circumstances. > > However the FESco apoints an arbitrator part wories me, the maintainer should > have a say in this too. There are some people in this community who > (unfortunately) mix about as well as fire and water. 1) the arbitrator does not _have_ to be _on_ FESCo 2) I think FESCo would take personal conflicts into account and try to reasonably appoint a neutral arbitrator. josh From jwboyer at jdub.homelinux.org Thu May 17 18:08:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 13:08:36 -0500 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C937A.9010403@redhat.com> References: <464C937A.9010403@redhat.com> Message-ID: <1179425316.9870.3.camel@zod.rchland.ibm.com> On Thu, 2007-05-17 at 13:40 -0400, Peter Jones wrote: > We were talking about this on #fedora-meeting, and I was asked to write > up my answer to the question of how to handle violations of the > packaging guidelines. > > It seems to me that the fundamental question is: what do I do when I > find a packaging problem? > > The answer should be: > > 1) Contact the maintainer about it. Start by filing a bug, work from > there. Be reasonable. > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > you with any good reasons why not, then send a note to FESCO. > Conversely, if you're a maintainer and somebody won't listen to reason > about when there is a good reason not to change something, contact FESCO. > 3) when FESCO is notified of a problem, they appoint somebody who they > trust to do the right thing to arbitrate the dispute. The arbitrator > has the right to decide right and wrong here. > 4) do what the arbitrator says. > 5) if a maintainer still doesn't fix a package, the arbitrator lets > FESCO know that we need to start the orphan package process. +1 josh From tcallawa at redhat.com Thu May 17 18:10:31 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 13:10:31 -0500 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C937A.9010403@redhat.com> References: <464C937A.9010403@redhat.com> Message-ID: <1179425431.6254.89.camel@localhost.localdomain> On Thu, 2007-05-17 at 13:40 -0400, Peter Jones wrote: > We were talking about this on #fedora-meeting, and I was asked to write > up my answer to the question of how to handle violations of the > packaging guidelines. > > It seems to me that the fundamental question is: what do I do when I > find a packaging problem? > > The answer should be: > > 1) Contact the maintainer about it. Start by filing a bug, work from > there. Be reasonable. > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > you with any good reasons why not, then send a note to FESCO. > Conversely, if you're a maintainer and somebody won't listen to reason > about when there is a good reason not to change something, contact FESCO. > 3) when FESCO is notified of a problem, they appoint somebody who they > trust to do the right thing to arbitrate the dispute. The arbitrator > has the right to decide right and wrong here. > 4) do what the arbitrator says. > 5) if a maintainer still doesn't fix a package, the arbitrator lets > FESCO know that we need to start the orphan package process. Worth a try. +1 ~spot From bpepple at fedoraproject.org Thu May 17 18:11:25 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 17 May 2007 14:11:25 -0400 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C937A.9010403@redhat.com> References: <464C937A.9010403@redhat.com> Message-ID: <1179425485.5843.7.camel@lincoln> On Thu, 2007-05-17 at 13:40 -0400, Peter Jones wrote: > We were talking about this on #fedora-meeting, and I was asked to write > up my answer to the question of how to handle violations of the > packaging guidelines. > > It seems to me that the fundamental question is: what do I do when I > find a packaging problem? > > The answer should be: > > 1) Contact the maintainer about it. Start by filing a bug, work from > there. Be reasonable. > 2) if the maintainer doesn't respond, or won't fix it and can't satisfy > you with any good reasons why not, then send a note to FESCO. > Conversely, if you're a maintainer and somebody won't listen to reason > about when there is a good reason not to change something, contact FESCO. > 3) when FESCO is notified of a problem, they appoint somebody who they > trust to do the right thing to arbitrate the dispute. The arbitrator > has the right to decide right and wrong here. > 4) do what the arbitrator says. > 5) if a maintainer still doesn't fix a package, the arbitrator lets > FESCO know that we need to start the orphan package process. > +1 /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Thu May 17 18:17:30 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 May 2007 14:17:30 -0400 Subject: Please tag Fixed in selinux-policy-2.6.4-6 for f7-final Message-ID: <464C9C3A.1010307@redhat.com> Many fixes to make suspend/resume work properly. Jeremy has verified changes. From dwalsh at redhat.com Thu May 17 18:19:37 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 May 2007 14:19:37 -0400 Subject: Please tag policycoreutils-2_0_16-2_fc7 to f7-final Message-ID: <464C9CB9.6070406@redhat.com> Policy gen tool had a couple of typos' that would make policy not compile correctly. (No risk change.) Can wait for updates if we are frozen. From pjones at redhat.com Thu May 17 18:31:58 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 14:31:58 -0400 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C9C91.3080801@hhs.nl> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> Message-ID: <464C9F9E.9040103@redhat.com> > In general this sounds reasonable, I especially like how this procedure > normally shouldn't come into play, but only becomes active under > exceptional circumstances. I really think this is *the* crucial criterion for a good plan. > However the FESco apoints an arbitrator part wories me, the maintainer > should have a say in this too. There are some people in this community > who (unfortunately) mix about as well as fire and water. Yeah, I didn't want to codify too strictly here; FESCO needs some levity in order to do a good job. In general, FESCO should appoint an arbitrator who a) isn't known to have problems dealing with either party, nor with the guys doing the guidelines, and b) doesn't have a specific vested interest in the package in question. Probably also they shouldn't be a FESCO member. If there's a serious conflict between people that's really getting out of hand, they and the board ultimately need to be the cooler heads that have to prevail. So really, the rationale behind my proposal is to leave FESCO ultimately *accountable* for resolution of disputes, but codifies a way that they can (and shall) appoint somebody reasonable from the community to act as ombudsman, and empowers that person to fulfill their responsibility. The real rule for everybody here is still "don't be an asshole". -- Peter From pjones at redhat.com Thu May 17 18:42:00 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 14:42:00 -0400 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C9F9E.9040103@redhat.com> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> <464C9F9E.9040103@redhat.com> Message-ID: <464CA1F8.4070703@redhat.com> Peter Jones wrote: > Yeah, I didn't want to codify too strictly here; FESCO needs some levity > in order to do a good job. Er, should have read "needs some latitude in order...". Sorry guys, I didn't mean to call you silly. -- Peter From bpepple at fedoraproject.org Thu May 17 18:43:13 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 17 May 2007 14:43:13 -0400 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C9F9E.9040103@redhat.com> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> <464C9F9E.9040103@redhat.com> Message-ID: <1179427393.5843.11.camel@lincoln> On Thu, 2007-05-17 at 14:31 -0400, Peter Jones wrote: > > In general, FESCO should appoint an arbitrator who a) isn't known to > have problems dealing with either party, nor with the guys doing the > guidelines, and b) doesn't have a specific vested interest in the > package in question. > > Probably also they shouldn't be a FESCO member. If there's a serious > conflict between people that's really getting out of hand, they and the > board ultimately need to be the cooler heads that have to prevail. +1. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Thu May 17 18:49:04 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 17 May 2007 14:49:04 -0400 Subject: odd file-requires in f7 packages Message-ID: <1179427744.10909.51.camel@rivendell> Hi folks, I sifted through all the file-requires in f7 from here: http://koji.fedoraproject.org/static-repos/f7-final-current/i386/ and I generated this list: http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt the format it: requiring-package:/file/it/requires The point of this list is to figure out why we have all these file-requires. A number of them seem downright silly and I think they need to be evaluated. The fewer file-requires that are outside of: /etc/* *bin/* the less often yum needs to look at complete filelists. This means less downloading for our users and less time wasted looking up things which are probably easier with a made-up provide. We discourage odd file-requires in the packaging guidelines and I'm just following up on some of them. comments/criticisms welcome and expected. :) -sv -------------- 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 overholt at redhat.com Thu May 17 18:47:17 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 17 May 2007 14:47:17 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179427744.10909.51.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> Message-ID: <1179427637.18825.13.camel@localhost.localdomain> On Thu, 2007-05-17 at 14:49 -0400, seth vidal wrote: > and I generated this list: > http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt The Eclipse ones are due to multilib and the inability to Require: nvr.arch. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Thu May 17 19:14:57 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 17 May 2007 21:14:57 +0200 Subject: odd file-requires in f7 packages In-Reply-To: <1179427744.10909.51.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> Message-ID: <464CA9B1.9070005@hhs.nl> seth vidal wrote: > Hi folks, > I sifted through all the file-requires in f7 from here: > http://koji.fedoraproject.org/static-repos/f7-final-current/i386/ > > and I generated this list: > http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt > Good work. These 2 are mine: xblast-0:2.10.4-2.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf chess-0:1.0-5.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf These are both games which used to be shipped with some none free font, since these fonts get openened and rendered directly not through X / Xftconfig, I know no other way to make sure those files are there, basicly the (patched) code for this games does: fopen("/usr/share/fonts/bitstream-vera/Vera.ttf", "r"). Since fonts have moved around sometimes in the past, and that will break this games, I've written the Requires as file requires, so that I get broken requires report from the requires checking scripts during the devel cycle instead of BZ entries from users that it crashes once the new font layout hits the streets in the next fedora release. I'm open to suggestions to doing this smarter. And ship a private copy of Vera.ttf is not a good suggestion! Regards, Hans From tcallawa at redhat.com Thu May 17 19:00:31 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 14:00:31 -0500 Subject: odd file-requires in f7 packages In-Reply-To: <1179427637.18825.13.camel@localhost.localdomain> References: <1179427744.10909.51.camel@rivendell> <1179427637.18825.13.camel@localhost.localdomain> Message-ID: <1179428431.6254.101.camel@localhost.localdomain> On Thu, 2007-05-17 at 14:47 -0400, Andrew Overholt wrote: > On Thu, 2007-05-17 at 14:49 -0400, seth vidal wrote: > > and I generated this list: > > http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt > > The Eclipse ones are due to multilib and the inability to Require: > nvr.arch. Couldn't this be hacked around with something like: Provides: %{name}(%{_arch}) ~spot From pjones at redhat.com Thu May 17 19:03:01 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 15:03:01 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179427637.18825.13.camel@localhost.localdomain> References: <1179427744.10909.51.camel@rivendell> <1179427637.18825.13.camel@localhost.localdomain> Message-ID: <464CA6E5.2090109@redhat.com> Andrew Overholt wrote: > On Thu, 2007-05-17 at 14:49 -0400, seth vidal wrote: >> and I generated this list: >> http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt > > The Eclipse ones are due to multilib and the inability to Require: > nvr.arch. But they all seem to be (essentially) eclipse-$foo.%{arch} requires eclipse.%{arch}. Couldn't we do something like: %package Provides: eclipse(%{arch}) ... %package -n eclipse-$foo Requires: eclipse(%{arch}) -- Peter From cweyl at alumni.drew.edu Thu May 17 19:05:59 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 17 May 2007 12:05:59 -0700 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464C937A.9010403@redhat.com> References: <464C937A.9010403@redhat.com> Message-ID: <7dd7ab490705171205u7c86ec79nc24adfbd8cb26379@mail.gmail.com> On 5/17/07, Peter Jones wrote: > 5) if a maintainer still doesn't fix a package, the arbitrator lets > FESCO know that we need to start the orphan package process. I like this, but think that step 5 should be something like "final enforcement rests with FESCo"... Give them a little more flexibility than just forcibly orphaning a package. -Chris -- Chris Weyl Ex astris, scientia From skvidal at linux.duke.edu Thu May 17 19:06:49 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 17 May 2007 15:06:49 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <464CA9B1.9070005@hhs.nl> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> Message-ID: <1179428809.10909.55.camel@rivendell> On Thu, 2007-05-17 at 21:14 +0200, Hans de Goede wrote: > seth vidal wrote: > > Hi folks, > > I sifted through all the file-requires in f7 from here: > > http://koji.fedoraproject.org/static-repos/f7-final-current/i386/ > > > > and I generated this list: > > http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt > > > > Good work. > > These 2 are mine: > xblast-0:2.10.4-2.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf > chess-0:1.0-5.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf > > These are both games which used to be shipped with some none free font, since > these fonts get openened and rendered directly not through X / Xftconfig, I > know no other way to make sure those files are there, basicly the (patched) > code for this games does: > fopen("/usr/share/fonts/bitstream-vera/Vera.ttf", "r"). Since fonts have moved > around sometimes in the past, and that will break this games, I've written the > Requires as file requires, so that I get broken requires report from the > requires checking scripts during the devel cycle instead of BZ entries from > users that it crashes once the new font layout hits the streets in the next > fedora release. > > I'm open to suggestions to doing this smarter. And ship a private copy of > Vera.ttf is not a good suggestion! I'd have two suggestions: 1. require bitstream-vera-fonts 2. monitor checkins to that package to see if the files have changed paths I know that's not much fun but then again - how often do fonts change their locations? -sv From nicolas.mailhot at laposte.net Thu May 17 19:06:37 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 May 2007 21:06:37 +0200 Subject: odd file-requires in f7 packages In-Reply-To: <464CA9B1.9070005@hhs.nl> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> Message-ID: <1179428797.3539.6.camel@rousalka.dyndns.org> Le jeudi 17 mai 2007 ? 21:14 +0200, Hans de Goede a ?crit : > I'm open to suggestions to doing this smarter. And ship a private copy of > Vera.ttf is not a good suggestion! At least require a DejaVu variant as Vera is been quietly deprecated. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pjones at redhat.com Thu May 17 19:09:40 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 15:09:40 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <464CA9B1.9070005@hhs.nl> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> Message-ID: <464CA874.8010408@redhat.com> Hans de Goede wrote: > xblast-0:2.10.4-2.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf > chess-0:1.0-5.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf > > These are both games which used to be shipped with some none free font, > since these fonts get openened and rendered directly not through X / > Xftconfig, I know no other way to make sure those files are there, > basicly the (patched) code for this games does: > fopen("/usr/share/fonts/bitstream-vera/Vera.ttf", "r"). Since fonts have > moved around sometimes in the past, and that will break this games, I've > written the Requires as file requires, so that I get broken requires > report from the requires checking scripts during the devel cycle instead > of BZ entries from users that it crashes once the new font layout hits > the streets in the next fedora release. > > I'm open to suggestions to doing this smarter. And ship a private copy > of Vera.ttf is not a good suggestion! Maybe it's worth introducing something like the following in the font packages: Provides: fontlayout(1, bitstream-vera/Vera.ttf) Alternately, we could just ban moving the fonts around and then you can do: Requires: bitstream-vera-fonts ;) -- Peter From skvidal at linux.duke.edu Thu May 17 19:10:37 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 17 May 2007 15:10:37 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179428797.3539.6.camel@rousalka.dyndns.org> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> <1179428797.3539.6.camel@rousalka.dyndns.org> Message-ID: <1179429037.10909.57.camel@rivendell> On Thu, 2007-05-17 at 21:06 +0200, Nicolas Mailhot wrote: > Le jeudi 17 mai 2007 ? 21:14 +0200, Hans de Goede a ?crit : > > > I'm open to suggestions to doing this smarter. And ship a private copy of > > Vera.ttf is not a good suggestion! > > At least require a DejaVu variant as Vera is been quietly deprecated. > or a virtual provides in both packages. -sv From pjones at redhat.com Thu May 17 19:10:09 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 15:10:09 -0400 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <7dd7ab490705171205u7c86ec79nc24adfbd8cb26379@mail.gmail.com> References: <464C937A.9010403@redhat.com> <7dd7ab490705171205u7c86ec79nc24adfbd8cb26379@mail.gmail.com> Message-ID: <464CA891.50608@redhat.com> Chris Weyl wrote: > On 5/17/07, Peter Jones wrote: >> 5) if a maintainer still doesn't fix a package, the arbitrator lets >> FESCO know that we need to start the orphan package process. > > I like this, but think that step 5 should be something like "final > enforcement rests with FESCo"... Give them a little more flexibility > than just forcibly orphaning a package. +1 -- Peter From mclasen at redhat.com Thu May 17 19:10:07 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 17 May 2007 15:10:07 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179427744.10909.51.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> Message-ID: <1179429007.3588.36.camel@dhcp83-33.boston.redhat.com> gdm-1:2.18.0-14.fc7.i386:/usr/share/desktop-menu-patches/gnome-gdmsetup.desktop I already filed this one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239822 From skvidal at linux.duke.edu Thu May 17 19:16:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 17 May 2007 15:16:21 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179429007.3588.36.camel@dhcp83-33.boston.redhat.com> References: <1179427744.10909.51.camel@rivendell> <1179429007.3588.36.camel@dhcp83-33.boston.redhat.com> Message-ID: <1179429381.10909.59.camel@rivendell> On Thu, 2007-05-17 at 15:10 -0400, Matthias Clasen wrote: > gdm-1:2.18.0-14.fc7.i386:/usr/share/desktop-menu-patches/gnome-gdmsetup.desktop > > I already filed this one: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239822 > > thank you! -sv From j.w.r.degoede at hhs.nl Thu May 17 19:33:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 17 May 2007 21:33:01 +0200 Subject: odd file-requires in f7 packages In-Reply-To: <1179428809.10909.55.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> <1179428809.10909.55.camel@rivendell> Message-ID: <464CADED.3050801@hhs.nl> seth vidal wrote: > On Thu, 2007-05-17 at 21:14 +0200, Hans de Goede wrote: >> seth vidal wrote: >>> Hi folks, >>> I sifted through all the file-requires in f7 from here: >>> http://koji.fedoraproject.org/static-repos/f7-final-current/i386/ >>> >>> and I generated this list: >>> http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt >>> >> Good work. >> >> These 2 are mine: >> xblast-0:2.10.4-2.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf >> chess-0:1.0-5.fc7.i386:/usr/share/fonts/bitstream-vera/Vera.ttf >> >> These are both games which used to be shipped with some none free font, since >> these fonts get openened and rendered directly not through X / Xftconfig, I >> know no other way to make sure those files are there, basicly the (patched) >> code for this games does: >> fopen("/usr/share/fonts/bitstream-vera/Vera.ttf", "r"). Since fonts have moved >> around sometimes in the past, and that will break this games, I've written the >> Requires as file requires, so that I get broken requires report from the >> requires checking scripts during the devel cycle instead of BZ entries from >> users that it crashes once the new font layout hits the streets in the next >> fedora release. >> >> I'm open to suggestions to doing this smarter. And ship a private copy of >> Vera.ttf is not a good suggestion! > > I'd have two suggestions: > 1. require bitstream-vera-fonts > 2. monitor checkins to that package to see if the files have changed > paths > > > I know that's not much fun but then again - how often do fonts change > their locations? > concidering the fact that most people will already have bitstream-vera-fonts installed (and assuming yum will find that the requires is fullfilled without downloading filelists in this case) I do not think the pain is worth the gain in this particular case. Regards, Hans From mclasen at redhat.com Thu May 17 19:21:39 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 17 May 2007 15:21:39 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179427744.10909.51.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> Message-ID: <1179429699.3588.38.camel@dhcp83-33.boston.redhat.com> gnome-screensaver-0:2.18.0-7.fc7.i386:/usr/share/gnome-screensaver/lock-dialog-system.glade This one is already gone in 2.18.0-8.fc7 From nicolas.mailhot at laposte.net Thu May 17 19:25:11 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 May 2007 21:25:11 +0200 Subject: odd file-requires in f7 packages In-Reply-To: <1179429037.10909.57.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> <1179428797.3539.6.camel@rousalka.dyndns.org> <1179429037.10909.57.camel@rivendell> Message-ID: <1179429911.3539.17.camel@rousalka.dyndns.org> Le jeudi 17 mai 2007 ? 15:10 -0400, seth vidal a ?crit : > On Thu, 2007-05-17 at 21:06 +0200, Nicolas Mailhot wrote: > > Le jeudi 17 mai 2007 ? 21:14 +0200, Hans de Goede a ?crit : > > > > > I'm open to suggestions to doing this smarter. And ship a private copy of > > > Vera.ttf is not a good suggestion! > > > > At least require a DejaVu variant as Vera is been quietly deprecated. > > > > or a virtual provides in both packages. Read again the original message: these apps are bypassing all the font infrastructure. They access fonts via hardcoded file names and locations (which do change in font packages, maybe not every month but often once during a release?). Font packages may be derivatives of the same original project but they definitely do *not* share the same filenames and a virtual just plain won't work. IMHO the file dep is perfectly logical there because that's what the app actually needs. It may not be yum's ideal model but that's how these apps are coded and pretending otherwise just leads to fast *BROKEN* deps (the other way is using alternatives, but there's no way in hell I'll add alternative support to my font packages just to make yum a little faster. Especially since the vast majority of users won't have these primitive apps installed and those who do can just wait a little more on updates) Correctness first please. ? old-style fedora releases not new style extended support ones -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From j.w.r.degoede at hhs.nl Thu May 17 19:40:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 17 May 2007 21:40:14 +0200 Subject: odd file-requires in f7 packages In-Reply-To: <1179429037.10909.57.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> <1179428797.3539.6.camel@rousalka.dyndns.org> <1179429037.10909.57.camel@rivendell> Message-ID: <464CAF9E.2070308@hhs.nl> seth vidal wrote: > On Thu, 2007-05-17 at 21:06 +0200, Nicolas Mailhot wrote: >> Le jeudi 17 mai 2007 ? 21:14 +0200, Hans de Goede a ?crit : >> >>> I'm open to suggestions to doing this smarter. And ship a private copy of >>> Vera.ttf is not a good suggestion! >> At least require a DejaVu variant as Vera is been quietly deprecated. >> > > or a virtual provides in both packages. > A virtual provide would only work if they both provided the same files, which afaik the don't. I agree with the goal to not use to much file dependencies. But in this case it really is a file dependency, the packages don't care where /usr/share/fonts/bitstream-vera/Vera.ttf comes from as long as its there. Offtopic: this reminds me of a discussion I had at fosdem with Jeff Johnson, with regards to some new rpm functionality he is working on, where dependencies like this could not only be resolved by other packages, but by the file actually being there, iow if the user put it there manually it would be fine too. I know this is offtopic, but it nicely demonstrates the point I'm trying to make, the fact that this really is a file dependency, I don't want fackae foo, I just want the file : /usr/share/fonts/bitstream-vera/Vera.ttf, and it should be a ttf font, which is kinda har to express in rpm. Regards, Hans From bugs.michael at gmx.net Thu May 17 19:30:24 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 17 May 2007 21:30:24 +0200 Subject: libstdc++ : Re: odd file-requires in f7 packages In-Reply-To: <1179427744.10909.51.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> Message-ID: <20070517213024.cc6fb8dc.bugs.michael@gmx.net> On Thu, 17 May 2007 14:49:04 -0400, seth vidal wrote: > and I generated this list: > http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt libstdc++-devel-0:4.1.2-12.i386:/usr/lib/libstdc++.so.6 comes from gcc41.spec: > Requires: [...], %{_prefix}/%{_lib}/libstdc++.so.6 while a dependency on the soname is automatic and *should* work just fine for multi-lib, too, since for 64-bit the automatic dependency is on libstdc++.so.6()(64bit) and not libstdc++.so.6 From nicolas.mailhot at laposte.net Thu May 17 19:30:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 May 2007 21:30:01 +0200 Subject: odd file-requires in f7 packages In-Reply-To: <464CADED.3050801@hhs.nl> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> <1179428809.10909.55.camel@rivendell> <464CADED.3050801@hhs.nl> Message-ID: <1179430201.3539.21.camel@rousalka.dyndns.org> Le jeudi 17 mai 2007 ? 21:33 +0200, Hans de Goede a ?crit : > concidering the fact that most people will already have bitstream-vera-fonts > installed $ rpm -q --whatrequires bitstream-vera-fonts no package requires bitstream-vera-fonts Previous releases had OpenOffice.org pulling Vera on the system. That's no longer the case. Actually there's little to no reason to install Vera on a F7 system nowadays. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From overholt at redhat.com Thu May 17 19:30:25 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 17 May 2007 15:30:25 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <464CA6E5.2090109@redhat.com> References: <1179427744.10909.51.camel@rivendell> <1179427637.18825.13.camel@localhost.localdomain> <464CA6E5.2090109@redhat.com> Message-ID: <1179430225.18825.19.camel@localhost.localdomain> On Thu, 2007-05-17 at 15:03 -0400, Peter Jones wrote: > Andrew Overholt wrote: > > On Thu, 2007-05-17 at 14:49 -0400, seth vidal wrote: > >> and I generated this list: > >> http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt > > > > The Eclipse ones are due to multilib and the inability to Require: > > nvr.arch. > > But they all seem to be (essentially) eclipse-$foo.%{arch} requires > eclipse.%{arch}. Couldn't we do something like: > > %package > Provides: eclipse(%{arch}) > ... > %package -n eclipse-$foo > Requires: eclipse(%{arch}) Maybe. I'm going on vacation tomorrow so I won't have time to look at this, but Ben Konrath may. Eclipse bugs go to him right now so I'm sure he'll comment if something's filed. Andrew -------------- 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 ajackson at redhat.com Thu May 17 19:35:15 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 17 May 2007 15:35:15 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179429911.3539.17.camel@rousalka.dyndns.org> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> <1179428797.3539.6.camel@rousalka.dyndns.org> <1179429037.10909.57.camel@rivendell> <1179429911.3539.17.camel@rousalka.dyndns.org> Message-ID: <1179430515.16274.94.camel@localhost.localdomain> On Thu, 2007-05-17 at 21:25 +0200, Nicolas Mailhot wrote: > Le jeudi 17 mai 2007 ? 15:10 -0400, seth vidal a ?crit : > > On Thu, 2007-05-17 at 21:06 +0200, Nicolas Mailhot wrote: > > > Le jeudi 17 mai 2007 ? 21:14 +0200, Hans de Goede a ?crit : > > > > > > > I'm open to suggestions to doing this smarter. And ship a private copy of > > > > Vera.ttf is not a good suggestion! > > > > > > At least require a DejaVu variant as Vera is been quietly deprecated. > > > > > > > or a virtual provides in both packages. > > Read again the original message: these apps are bypassing all the font > infrastructure. They access fonts via hardcoded file names and locations > (which do change in font packages, maybe not every month but often once > during a release?). > > Font packages may be derivatives of the same original project but they > definitely do *not* share the same filenames and a virtual just plain > won't work. > > IMHO the file dep is perfectly logical there because that's what the app > actually needs. It may not be yum's ideal model but that's how these > apps are coded and pretending otherwise just leads to fast *BROKEN* deps It's not anyone's ideal model. rpm happens to be the only packaging system that lets you do file provides. How does Debian do it? Alternatively, someone just port the damn thing to Xft already. - ajax From pjones at redhat.com Thu May 17 19:56:17 2007 From: pjones at redhat.com (Peter Jones) Date: Thu, 17 May 2007 15:56:17 -0400 Subject: odd file-requires in f7 packages In-Reply-To: <1179429911.3539.17.camel@rousalka.dyndns.org> References: <1179427744.10909.51.camel@rivendell> <464CA9B1.9070005@hhs.nl> <1179428797.3539.6.camel@rousalka.dyndns.org> <1179429037.10909.57.camel@rivendell> <1179429911.3539.17.camel@rousalka.dyndns.org> Message-ID: <464CB361.4060305@redhat.com> Nicolas Mailhot wrote: > Correctness first please. One might argue for fixing the code to actually use the font infrastructure. -- Peter From bugs.michael at gmx.net Thu May 17 20:14:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 17 May 2007 22:14:55 +0200 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <20070109210622.8b03dc7f.bugs.michael@gmx.net> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> Message-ID: <20070517221455.36bb2ac4.bugs.michael@gmx.net> On Tue, 9 Jan 2007 21:06:22 +0100, Michael Schwendt wrote: > This is just a reminder. > > These are all non-explicit package conflicts found in FE development. > I've filed several tickets plus a few more for FE<=6 (check out the > FE7Target bug) long ago. Still present in Rawhide 20070517 are: clearsilver - 0.10.4-3.fc7.i386 File conflict with: csound - 5.03.0-13.fc7.i386 /usr/bin/cs csound - 5.03.0-13.fc7.i386 File conflict with: clearsilver - 0.10.4-3.fc7.i386 /usr/bin/cs File conflict with: html-xml-utils - 3.7-4.fc6.i386 /usr/bin/extract File conflict with: libextractor - 0.5.17a-1.fc7.i386 /usr/bin/extract cyrus-imapd - 2.3.8-3.fc7.i386 File conflict with: uw-imap - 2006h-1.fc7.i386 /etc/pam.d/imap /etc/pam.d/pop /usr/share/man/man8/imapd.8.gz fish - 1.21.12-1.fc6.i386 File conflict with: html-xml-utils - 3.7-4.fc6.i386 /usr/bin/count /usr/share/man/man1/count.1.gz html-xml-utils - 3.7-4.fc6.i386 File conflict with: csound - 5.03.0-13.fc7.i386 /usr/bin/extract File conflict with: fish - 1.21.12-1.fc6.i386 /usr/bin/count /usr/share/man/man1/count.1.gz File conflict with: libextractor - 0.5.17a-1.fc7.i386 /usr/bin/extract libextractor - 0.5.17a-1.fc7.i386 File conflict with: csound - 5.03.0-13.fc7.i386 /usr/bin/extract File conflict with: html-xml-utils - 3.7-4.fc6.i386 /usr/bin/extract plib-devel - 1.8.4-8.fc6.i386 File conflict with: plib16-devel - 1.6.0-6.fc6.i386 /usr/include/plib/fnt.h /usr/include/plib/js.h /usr/include/plib/netBuffer.h /usr/include/plib/netChannel.h /usr/include/plib/netMessage.h /usr/include/plib/netMonitor.h /usr/include/plib/netSocket.h /usr/include/plib/pu.h /usr/include/plib/sg.h /usr/include/plib/sl.h /usr/include/plib/slPortability.h /usr/include/plib/sm.h /usr/include/plib/ssg.h /usr/include/plib/ssgAux.h /usr/include/plib/ssgKeyFlier.h /usr/include/plib/ssgaWaveSystem.h /usr/include/plib/ssgconf.h /usr/include/plib/ul.h /usr/include/plib/ulRTTI.h plib16-devel - 1.6.0-6.fc6.i386 File conflict with: plib-devel - 1.8.4-8.fc6.i386 /usr/include/plib/fnt.h /usr/include/plib/js.h /usr/include/plib/netBuffer.h /usr/include/plib/netChannel.h /usr/include/plib/netMessage.h /usr/include/plib/netMonitor.h /usr/include/plib/netSocket.h /usr/include/plib/pu.h /usr/include/plib/sg.h /usr/include/plib/sl.h /usr/include/plib/slPortability.h /usr/include/plib/sm.h /usr/include/plib/ssg.h /usr/include/plib/ssgAux.h /usr/include/plib/ssgKeyFlier.h /usr/include/plib/ssgaWaveSystem.h /usr/include/plib/ssgconf.h /usr/include/plib/ul.h /usr/include/plib/ulRTTI.h uw-imap - 2006h-1.fc7.i386 File conflict with: cyrus-imapd - 2.3.8-3.fc7.i386 /etc/pam.d/imap /etc/pam.d/pop /usr/share/man/man8/imapd.8.gz From Michael_E_Brown at dell.com Thu May 17 20:16:24 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 17 May 2007 15:16:24 -0500 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <464CA1F8.4070703@redhat.com> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> <464C9F9E.9040103@redhat.com> <464CA1F8.4070703@redhat.com> Message-ID: <20070517201624.GA4966@humbolt.us.dell.com> On Thu, May 17, 2007 at 02:42:00PM -0400, Peter Jones wrote: > Peter Jones wrote: > >Yeah, I didn't want to codify too strictly here; FESCO needs some levity > >in order to do a good job. > > Er, should have read "needs some latitude in order...". Sorry guys, I > didn't mean to call you silly. So, what, you guys want a bunch of Dell laptops for everybody? :) -- Michael 'too silly' Brown For thos who do not get the joke: http://www.dell.com/content/products/category.aspx/latit From tcallawa at redhat.com Thu May 17 20:25:00 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 15:25:00 -0500 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <20070517201624.GA4966@humbolt.us.dell.com> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> <464C9F9E.9040103@redhat.com> <464CA1F8.4070703@redhat.com> <20070517201624.GA4966@humbolt.us.dell.com> Message-ID: <1179433500.6254.108.camel@localhost.localdomain> On Thu, 2007-05-17 at 15:16 -0500, Michael E Brown wrote: > On Thu, May 17, 2007 at 02:42:00PM -0400, Peter Jones wrote: > > Peter Jones wrote: > > >Yeah, I didn't want to codify too strictly here; FESCO needs some levity > > >in order to do a good job. > > > > Er, should have read "needs some latitude in order...". Sorry guys, I > > didn't mean to call you silly. > > So, what, you guys want a bunch of Dell laptops for everybody? :) Gotta test suspend/resume with something. I'll be sending my mailing address in private. ;) ~spot From jwboyer at jdub.homelinux.org Thu May 17 20:26:03 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 15:26:03 -0500 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <20070517201624.GA4966@humbolt.us.dell.com> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> <464C9F9E.9040103@redhat.com> <464CA1F8.4070703@redhat.com> <20070517201624.GA4966@humbolt.us.dell.com> Message-ID: <1179433563.9870.9.camel@zod.rchland.ibm.com> On Thu, 2007-05-17 at 15:16 -0500, Michael E Brown wrote: > On Thu, May 17, 2007 at 02:42:00PM -0400, Peter Jones wrote: > > Peter Jones wrote: > > >Yeah, I didn't want to codify too strictly here; FESCO needs some levity > > >in order to do a good job. > > > > Er, should have read "needs some latitude in order...". Sorry guys, I > > didn't mean to call you silly. > > So, what, you guys want a bunch of Dell laptops for everybody? :) I'll gladly take one. If you want me mailing address, just let me know ;) josh 'hoping Michael is a sucker' From notting at redhat.com Thu May 17 20:27:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 May 2007 16:27:33 -0400 Subject: packages that could need ExclusiveArch updated Message-ID: <20070517202733.GA6900@nostromo.devel.redhat.com> The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. This may need adjusted if they want to build in the future: 915resolution alsa-tools glest gnome-applet-sensors google-perftools mono-debugger stripesnoop xeuphoric xfce4-sensors-plugin Bill From Michael_E_Brown at dell.com Thu May 17 20:33:07 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 17 May 2007 15:33:07 -0500 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <1179433563.9870.9.camel@zod.rchland.ibm.com> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> <464C9F9E.9040103@redhat.com> <464CA1F8.4070703@redhat.com> <20070517201624.GA4966@humbolt.us.dell.com> <1179433563.9870.9.camel@zod.rchland.ibm.com> Message-ID: <20070517203306.GB4966@humbolt.us.dell.com> On Thu, May 17, 2007 at 03:26:03PM -0500, Josh Boyer wrote: > On Thu, 2007-05-17 at 15:16 -0500, Michael E Brown wrote: > > On Thu, May 17, 2007 at 02:42:00PM -0400, Peter Jones wrote: > > > Peter Jones wrote: > > > >Yeah, I didn't want to codify too strictly here; FESCO needs some levity > > > >in order to do a good job. > > > > > > Er, should have read "needs some latitude in order...". Sorry guys, I > > > didn't mean to call you silly. > > > > So, what, you guys want a bunch of Dell laptops for everybody? :) > > I'll gladly take one. If you want me mailing address, just let me > know ;) > > josh 'hoping Michael is a sucker' Yeah... You'll notice my message had a link at the bottom where you could order one. :) -- Michael "they dont pay me enough to go around handing out laptops" From cweyl at alumni.drew.edu Thu May 17 21:02:47 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 17 May 2007 14:02:47 -0700 Subject: An alternate proposal to answer the guidelines question. In-Reply-To: <20070517203306.GB4966@humbolt.us.dell.com> References: <464C937A.9010403@redhat.com> <464C9C91.3080801@hhs.nl> <464C9F9E.9040103@redhat.com> <464CA1F8.4070703@redhat.com> <20070517201624.GA4966@humbolt.us.dell.com> <1179433563.9870.9.camel@zod.rchland.ibm.com> <20070517203306.GB4966@humbolt.us.dell.com> Message-ID: <7dd7ab490705171402v642a1166u60938ca46e7391e1@mail.gmail.com> On 5/17/07, Michael E Brown wrote: > You'll notice my message had a link at the bottom where you could order > one. :) I thought you had a coupon code for this. like "LOVEFEDORALOVELAPTOPS"? O:-) -Chris -- Chris Weyl Ex astris, scientia From Axel.Thimm at ATrpms.net Thu May 17 21:31:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 May 2007 23:31:06 +0200 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179421175.26613.3.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> <1179417708.6254.81.camel@localhost.localdomain> <20070517164258.GA25203@neu.nirvana> <1179421175.26613.3.camel@localhost.localdomain> Message-ID: <20070517213106.GB25604@neu.nirvana> On Thu, May 17, 2007 at 09:59:35AM -0700, Toshio Kuratomi wrote: > On Thu, 2007-05-17 at 18:42 +0200, Axel Thimm wrote: > > On Thu, May 17, 2007 at 11:01:48AM -0500, Tom spot Callaway wrote: > > > On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > > > > Christopher Blizzard wrote: > > > > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > > > > >> All we're really trying to do is make good packages. We've tried > > > > >> really > > > > >> hard to make guidelines that lead to good, clean, > > > > >> maintainable-long-after-you-are-dead packages. > > > > >> > > > > > > > > > > I hear what you are saying and I understand. What I'm saying is that > > > > > there's a fine line between making good packages and going over the > > > > > edge. So in your example, documenting is good. But if you end up with > > > > > an exception process? I think that probably crosses the line. Dispute > > > > > resolution, maybe. But I just worry that we're going somewhere we don't > > > > > want to be. Not sure how to properly put this into words. > > > > > > > > I'm totally in agreement that an exception process isn't somewhere we > > > > want to go. Arbitration when there's a dispute causes less impedance to > > > > actually getting things done, while still achieving the same goals. > > > > > > But we're not even aware that there is a dispute, when people just > > > decide not to follow the guidelines. There is no "Packaging QA" group, > > > constantly auditing spec files. > > > > This would still be the same issue if guidelines would tunr into laws > > with exception policies. "If no one sees the crime, there was no > > crime." > > > > This thread seems to have been spawn by some explicit example of a > > packager consciously violating the guidelines. But some of us don't > > know what the example is. Could you post in some URL? Maybe the issue > > is not solved by turning guidelines into stone, but by something else. > > Top of thread: > https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00351.html > > Where it starts to get "interesting": > https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00459.html I see, it's about static libs and changelog entries. Well, in fact understand and share the packager's viewpoint and frustration in not getting his issue through. I don't want to roll up these specific topics again, and what these topics are today, others will be tomorrow. Instead of an iron set of rules where action needs to be taken to create exceptions we better keep soft rules with a mechanism to take something up to fesco if it is considered worth it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mszpak at wp.pl Thu May 17 21:36:40 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Thu, 17 May 2007 23:36:40 +0200 Subject: upgrade to scons 0.96.96 In-Reply-To: <1178908700.24228.2.camel@localhost.localdomain> References: <1178908700.24228.2.camel@localhost.localdomain> Message-ID: <464CCAE8.1070008@wp.pl> On 2007-05-11 20:38:20 +0200, G?rard Milmeister wrote: > It appears that some packages in review need a newer scons version than > the stable 0.96.1. See: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236517 > Is it ok to upgrade, or would some packages currently in the repository > break? The SCons Foundation released the new "stable" version of Scons - 0.97. https://sourceforge.net/project/shownotes.php?release_id=509219 Regards Marcin From Axel.Thimm at ATrpms.net Thu May 17 21:39:09 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 17 May 2007 23:39:09 +0200 Subject: Plan for tomorrows (20070517) FESCO meeting In-Reply-To: <1179418977.5843.6.camel@lincoln> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <1179416949.17014.16.camel@localhost.localdomain> <464C7B34.7020002@redhat.com> <1179418977.5843.6.camel@lincoln> Message-ID: <20070517213909.GC25604@neu.nirvana> On Thu, May 17, 2007 at 12:22:57PM -0400, Brian Pepple wrote: > On Thu, 2007-05-17 at 11:56 -0400, Peter Jones wrote: > > Christopher Blizzard wrote: > > > On Thu, 2007-05-17 at 10:31 -0500, Tom "spot" Callaway wrote: > > >> All we're really trying to do is make good packages. We've tried > > >> really > > >> hard to make guidelines that lead to good, clean, > > >> maintainable-long-after-you-are-dead packages. > > >> > > > > > > I hear what you are saying and I understand. What I'm saying is that > > > there's a fine line between making good packages and going over the > > > edge. So in your example, documenting is good. But if you end up with > > > an exception process? I think that probably crosses the line. Dispute > > > resolution, maybe. But I just worry that we're going somewhere we don't > > > want to be. Not sure how to properly put this into words. > > > > I'm totally in agreement that an exception process isn't somewhere we > > want to go. Arbitration when there's a dispute causes less impedance to > > actually getting things done, while still achieving the same goals. > > How would you suggest we deal with maintainers that outright say they > choose to ignore the packaging guidelines? We drop their packages and ban them from rentering Fedora for at least a full release cycle. We should start with the kernel package as an exemplary beste before F7 goes gold. ;) Really, the core packages (core as in most important, not as in Fedora Core) mostly violate the packaging guidelines sometimes w/o reason especially in areas which are considered sacred, far more than guidelines about statics libs or changelogs. Still we look over it. We kindly suggest that the kernel start proper versioning and not only for the guidelines' sake (it is also technically sane to follow upstream versioning which would be in line with the guidelines). But if the kernel package maintainers don't want to follow the guidelines we let them, and just retry changing their minds every now and then. We won't send in the Package Guidelines Enforment Task Force (also known as PGETF) to beat them up until they succumb. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Thu May 17 21:43:34 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 17 May 2007 16:43:34 -0500 Subject: packages that could need ExclusiveArch updated In-Reply-To: <20070517202733.GA6900@nostromo.devel.redhat.com> References: <20070517202733.GA6900@nostromo.devel.redhat.com> Message-ID: <1179438214.6254.112.camel@localhost.localdomain> On Thu, 2007-05-17 at 16:27 -0400, Bill Nottingham wrote: > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. This > may need adjusted if they want to build in the future: > google-perftools > stripesnoop Committed changes to add ppc64 to ExcludeArch to both packages. I've not requested rebuilds. ~spot From notting at redhat.com Thu May 17 22:04:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 May 2007 18:04:43 -0400 Subject: packages that could need ExclusiveArch updated In-Reply-To: <1179438214.6254.112.camel@localhost.localdomain> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <1179438214.6254.112.camel@localhost.localdomain> Message-ID: <20070517220443.GA8569@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > On Thu, 2007-05-17 at 16:27 -0400, Bill Nottingham wrote: > > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. This > > may need adjusted if they want to build in the future: > > > google-perftools > > stripesnoop > > Committed changes to add ppc64 to ExcludeArch to both packages. I've not > requested rebuilds. Yeah, sorry I wasn't clear - this isn't something people would want to rebuild for *now*; just something that makes their package much more likely to build right in the future. Bill From bnocera at redhat.com Thu May 17 22:58:19 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 17 May 2007 23:58:19 +0100 Subject: Please tag Fixed in selinux-policy-2.6.4-6 for f7-final In-Reply-To: <464C9C3A.1010307@redhat.com> References: <464C9C3A.1010307@redhat.com> Message-ID: <1179442699.4787.44.camel@cookie.hadess.net> On Thu, 2007-05-17 at 14:17 -0400, Daniel J Walsh wrote: > Many fixes to make suspend/resume work properly. Jeremy has verified > changes. Tagging requests are supposed to go to rel-eng at fedoraproject.org IIRC From christoph.wickert at nurfuerspam.de Thu May 17 23:25:39 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 18 May 2007 01:25:39 +0200 Subject: packages that could need ExclusiveArch updated In-Reply-To: <20070517220443.GA8569@nostromo.devel.redhat.com> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <1179438214.6254.112.camel@localhost.localdomain> <20070517220443.GA8569@nostromo.devel.redhat.com> Message-ID: <1179444339.5310.1.camel@hal9000.oberschlesier.lan> Am Donnerstag, den 17.05.2007, 18:04 -0400 schrieb Bill Nottingham: > Tom spot Callaway (tcallawa at redhat.com) said: > > On Thu, 2007-05-17 at 16:27 -0400, Bill Nottingham wrote: > > > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. This > > > may need adjusted if they want to build in the future: > > > > > google-perftools > > > stripesnoop > > > > Committed changes to add ppc64 to ExcludeArch to both packages. I've not > > requested rebuilds. > > Yeah, sorry I wasn't clear - this isn't something people would want to > rebuild for *now*; Ah, sorry, I didn't see this message before, so I did a new xfce4-sensors-plugin build for devel. Chris From dennis at ausil.us Fri May 18 01:25:10 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 17 May 2007 20:25:10 -0500 Subject: packages that could need ExclusiveArch updated In-Reply-To: <20070517202733.GA6900@nostromo.devel.redhat.com> References: <20070517202733.GA6900@nostromo.devel.redhat.com> Message-ID: <200705172025.16801.dennis@ausil.us> Once upon a time Thursday 17 May 2007, Bill Nottingham wrote: > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. > This may need adjusted if they want to build in the future: > > 915resolution > alsa-tools > glest > gnome-applet-sensors > google-perftools > mono-debugger > stripesnoop > xeuphoric > xfce4-sensors-plugin > > Bill I'd much rather see these use ExclusiveArch: x86_64 %{ix86} so they dont have issues for people building on other archs. im assuming the reason ppc is excluded is due to endianess issues Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri May 18 01:25:40 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 May 2007 21:25:40 -0400 Subject: packages that could need ExclusiveArch updated In-Reply-To: <200705172025.16801.dennis@ausil.us> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <200705172025.16801.dennis@ausil.us> Message-ID: <20070518012540.GA10019@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. > > This may need adjusted if they want to build in the future: > > > > 915resolution > > alsa-tools > > glest > > gnome-applet-sensors > > google-perftools > > mono-debugger > > stripesnoop > > xeuphoric > > xfce4-sensors-plugin > > I'd much rather see these use ExclusiveArch: x86_64 %{ix86} so they dont have > issues for people building on other archs. im assuming the reason ppc is > excluded is due to endianess issues Looking at the list: - *sensors* is 'whatever arches lm-sensors exists on' - probably x86_64 %{ix86} - ditto for 915resolution - mono-debugger presumably is supposed to match arches mono is available for. Theoretically, it should be building on ppc. The others I'm not sure why they exclude ppc. Bill From jwboyer at jdub.homelinux.org Fri May 18 01:26:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 17 May 2007 20:26:59 -0500 Subject: packages that could need ExclusiveArch updated In-Reply-To: <200705172025.16801.dennis@ausil.us> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <200705172025.16801.dennis@ausil.us> Message-ID: <1179451620.16646.1.camel@vader.jdub.homelinux.org> On Thu, 2007-05-17 at 20:25 -0500, Dennis Gilmore wrote: > Once upon a time Thursday 17 May 2007, Bill Nottingham wrote: > > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. > > This may need adjusted if they want to build in the future: > > > > 915resolution > > alsa-tools > > glest > > gnome-applet-sensors > > google-perftools > > mono-debugger > > stripesnoop > > xeuphoric > > xfce4-sensors-plugin > > > > Bill > I'd much rather see these use ExclusiveArch: x86_64 %{ix86} so they dont have > issues for people building on other archs. im assuming the reason ppc is > excluded is due to endianess issues Well... probably not for 915resolution. That just doesn't exist on ppc/ppc64. Others I have no idea. josh From notting at redhat.com Fri May 18 01:31:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 May 2007 21:31:06 -0400 Subject: packages that could need ExclusiveArch updated In-Reply-To: <1179451620.16646.1.camel@vader.jdub.homelinux.org> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <200705172025.16801.dennis@ausil.us> <1179451620.16646.1.camel@vader.jdub.homelinux.org> Message-ID: <20070518013106.GB10019@nostromo.devel.redhat.com> Josh Boyer (jwboyer at jdub.homelinux.org) said: > Well... probably not for 915resolution. That just doesn't exist on > ppc/ppc64. Others I have no idea. True it doesn't exist on ppc, but setting an exclusivearch for 'architectures that would have a intel 9xx chipset' might be more accurate. Bill From dennis at ausil.us Fri May 18 01:46:59 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 17 May 2007 20:46:59 -0500 Subject: packages that could need ExclusiveArch updated In-Reply-To: <20070518013106.GB10019@nostromo.devel.redhat.com> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <1179451620.16646.1.camel@vader.jdub.homelinux.org> <20070518013106.GB10019@nostromo.devel.redhat.com> Message-ID: <200705172046.59805.dennis@ausil.us> Once upon a time Thursday 17 May 2007, Bill Nottingham wrote: > Josh Boyer (jwboyer at jdub.homelinux.org) said: > > Well... probably not for 915resolution. That just doesn't exist on > > ppc/ppc64. Others I have no idea. > > > > True it doesn't exist on ppc, but setting an exclusivearch for > 'architectures that would have a intel 9xx chipset' might be more accurate. > > Bill Thats exactly the point i was trying to make. if a package really is just for one or two archs make it so by using ExclusiveArch it helps all those people who build for other archs. there is at least sparc, alpha, and ia64 out there probably mips, arm and others also. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri May 18 01:53:04 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 May 2007 03:53:04 +0200 Subject: packages that could need ExclusiveArch updated In-Reply-To: <20070518012540.GA10019@nostromo.devel.redhat.com> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <200705172025.16801.dennis@ausil.us> <20070518012540.GA10019@nostromo.devel.redhat.com> Message-ID: <20070518015304.GA4496@neu.nirvana> On Thu, May 17, 2007 at 09:25:40PM -0400, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. > > > This may need adjusted if they want to build in the future: > > > > > > 915resolution > > > alsa-tools > > > glest > > > gnome-applet-sensors > > > google-perftools > > > mono-debugger > > > stripesnoop > > > xeuphoric > > > xfce4-sensors-plugin > > > > I'd much rather see these use ExclusiveArch: x86_64 %{ix86} so they dont have > > issues for people building on other archs. im assuming the reason ppc is > > excluded is due to endianess issues > > Looking at the list: > > - *sensors* is 'whatever arches lm-sensors exists on' - probably x86_64 %{ix86} And ppc. > - ditto for 915resolution > - mono-debugger presumably is supposed to match arches mono is available for. > Theoretically, it should be building on ppc. > > The others I'm not sure why they exclude ppc. > > Bill > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri May 18 02:29:24 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 May 2007 22:29:24 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705141710.20460.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> Message-ID: <20070518022924.GA10478@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > At this time we will also be branching CVS for F-7. Builds from the devel/ > branch will be given the dist-f8 tag and held until rawhide starts composing > from dist-f8 (all dist-fc7 builds will be inherited by dist-f8 as well). > Builds from the F-7/ branch will be given the dist-fc7-updates-candidate tag > and can either wait for bodhi (the update tool) to become available to > request as an update to Fedora 7, or if it is a release blocker be tagged > with f7-final (after emailing rel-eng at fedoraproject.org) > > Mail will be sent prior to the CVS branching as there will be a small outage > during the branching. This will be starting very shortly. Mail will be sent when CVS is back online. Bill From rc040203 at freenet.de Fri May 18 04:32:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 06:32:33 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705151322.01037.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <200705151322.01037.jkeating@redhat.com> Message-ID: <1179462753.4735.894.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 13:22 -0400, Jesse Keating wrote: > On Tuesday 15 May 2007 13:15:07 Michael Schwendt wrote: > > Eh? What has this comment to do here? Or have you realised that too many > > users are burnt by the frequent updates and upgrades that are pushed out > > to Fedora Core 5 and Fedora Core 6? AFAICT, most of them wandered off because of updates misbehaving, due to poor packaging, broken mirrors and yum suckage, not because of packages misbehaving at run-time. > That is the #1 complaint by users who > > have wandered off to Ubuntu, for example. Released Updates which break > > something badly. Wrapped into nice words in good-looking update > > announcements, which advertise everything but the regression and > > breakage. How does that help us? The testing is missing, not the > > announcements. Exactly - marketing eye-candy. > Correct the testing, Wrong, correct the release procedures. E.g. to me it's incomprehensible why Fedora doesn't automatically block out packages with known broken deps. > forcing things to go into an updates-testing queue before > going out to the rest of the world. Once, again, this only makes sense if anybody uses it and if those using it are able to perform real and systematic tests. Experience tells, such "testing" is largely being ignored by the masses. Experience tells, packages in such "testing" repos are only used by users if they are facing real problems (such as with the kernels). Experience tells, hardly anybody is able to perform "real and systematic tests" and if maintainers are able to handle reports. Experience tells, maintainers often ignore negative feedback on "tests" ("Your case is a rare corner-case, I won't update the package for it") or can't avoid to fall back to "sorry, I can't do much about it". > Announcement about what has changed and > what should be tested, the ability to pull something from -testing before it > hits the wide world. Ralf's statement is that we shouldn't bother, Announcements don't change anything about it. > and we should just use our end users for our testing purposes. I say: Just as throughout all the years before, you should use rawhide for testing and avoid any disruptive changes on stable. > > Anyway, I wonder what this has to do with a sudden and late freeze of > > Extras' packages? Not much, except that forcing maintainers to manually writing announcements (which will widely be ignored) is yet another additional regression in workflow imposing further load on maintainers. Ralf From rc040203 at freenet.de Fri May 18 05:15:00 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 07:15:00 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179238326.3084.64.camel@zod.rchland.ibm.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179175507.19267.42.camel@vader.jdub.homelinux.org> <1179182588.4735.374.camel@mccallum.corsepiu.local> <1179189501.19267.51.camel@vader.jdub.homelinux.org> <1179235385.4735.474.camel@mccallum.corsepiu.local> <1179236633.3084.51.camel@zod.rchland.ibm.com> <1179237388.4735.486.camel@mccallum.corsepiu.local> <1179238326.3084.64.camel@zod.rchland.ibm.com> Message-ID: <1179465300.4735.903.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 09:12 -0500, Josh Boyer wrote: > On Tue, 2007-05-15 at 15:56 +0200, Ralf Corsepius wrote: > > > > I really don't have a problem in orphaning these packages, because my > > > > interest in continuing to struggle with packages in Fedora drops by the > > > > minute. > > Right now koji doesn't have any usable documentation nor is the workflow > > You keep saying that, but what documentation are you looking for? No man-page, no docs on .koji (--nowait), no docs/man on koji.conf, no reasonable error messages if koji fails (It did several times because some servers were inaccessible) isn't setup correctly locally (/usr/bin/fedora-packager-setup.sh wasn't mentioned anywhere until somebody fixed it recently - Other people also complained about this). > > now also seem to have inconsistencies been rawhide and the buildsystem. > > Yesterday, I was facing packages which built in rawhide but failed in > > the buildsystem). > > Which and how did they fail? perl-modules built flawlessly in a local fc7-mock ("make mock"), but failed in koji ("make build"). Ralf From peter at thecodergeek.com Fri May 18 06:01:41 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Thu, 17 May 2007 23:01:41 -0700 Subject: odd file-requires in f7 packages In-Reply-To: <1179427744.10909.51.camel@rivendell> References: <1179427744.10909.51.camel@rivendell> Message-ID: <1179468102.30167.14.camel@tuxhugs> On Thu, 2007-05-17 at 14:49 -0400, seth vidal wrote: > and I generated this list: > http://linux.duke.edu/~skvidal/misc/what-requires-crazy-files.txt > Which contains: > openbox-0:3.3.1-6.fc7.i386:/usr/share/gnome/wm-properties This one was because no package previously owned this dir, so when it became part of the gnome-session package (#216514), I added it as a dependency instead of providing it as part of the openbox package (as had been done earlier) so that it would not conflict with a system package (gnome-session): * Thu Nov 23 2006 Peter Gordon - 3.3.1-4 - Don't own %%{_datadir}/gnome/wm-properties anymore, as that's now owned by gnome-session in Rawhide and we should not have ownership conflicts with Core packages. > openbox-0:3.3.1-6.fc7.i386:/usr/share/themes This one is due to the fact that Openbox places themes into /usr/share/themes; so it owns the theme folders it creates; but not the parent. Should I add this ownership to the spec file and remove the requirement? (Right now, this directory is provided by either gtk2-engines and metacity.) > xine-plugin-0:1.0-3.fc7.i386:/usr/lib/mozilla/plugins > gxine-mozplugin-0:0.5.11-4.fc7.i386:/usr/lib/mozilla/plugins > mozilla-opensc-signer-0:0.11.2-2.fc7.i386:/usr/lib/mozilla/plugins > gnash-plugin-0:0.7.2-2.fc7.i386:/usr/lib/mozilla/plugins > HelixPlayer-plugin-1:1.0.7-5.fc7.i386:/usr/lib/mozilla/plugins These (not my packages) are due to the fact the user could potentially have Firefox, XULrunner, or some other Gecko-using browser (KHTML/Konqerour too?) which defaults to looking in this directory for plugins. Thus, any of these browsers can provide the directory ownership and hardcoding a dependency on a specific browser seems too intrusive.| Thanks, Seth! -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pnasrat at redhat.com Fri May 18 06:15:47 2007 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 18 May 2007 07:15:47 +0100 Subject: OUTAGE cvs.fedora.redhat.com down Message-ID: <1179468947.9205.14.camel@enki.eridu> The infrastructure team are hard at work with the branch, but it's taking longer than anicipated (as outages seem to...). If you see messages such as: ssh: connect to host cvs.fedora.redhat.com port 22: Connection refused cvs [log aborted]: end of file from server (consult above messages if any) Don't be alarmed it's known about and is due to cvs being offline for the branch. Normal service will be restored following the branch. We apologise for any inconvenience. Paul Nasrat From ville.skytta at iki.fi Fri May 18 07:10:55 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 18 May 2007 10:10:55 +0300 Subject: packages that could need ExclusiveArch updated In-Reply-To: <20070518015304.GA4496@neu.nirvana> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <20070518012540.GA10019@nostromo.devel.redhat.com> <20070518015304.GA4496@neu.nirvana> Message-ID: <200705181010.55936.ville.skytta@iki.fi> On Friday 18 May 2007, Axel Thimm wrote: > On Thu, May 17, 2007 at 09:25:40PM -0400, Bill Nottingham wrote: > > > > - *sensors* is 'whatever arches lm-sensors exists on' - probably x86_64 > > %{ix86} > > And ppc. Not in my current CVS working dir, but alpha is there: $ grep Arch: lm_sensors.spec ExclusiveArch: alpha %{ix86} x86_64 From nicolas.mailhot at laposte.net Fri May 18 09:02:56 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 18 May 2007 11:02:56 +0200 Subject: odd file-requires in f7 packages In-Reply-To: <1179468102.30167.14.camel@tuxhugs> References: <1179427744.10909.51.camel@rivendell> <1179468102.30167.14.camel@tuxhugs> Message-ID: <1179478976.5137.9.camel@rousalka.dyndns.org> Le jeudi 17 mai 2007 ? 23:01 -0700, Peter Gordon a ?crit : > > openbox-0:3.3.1-6.fc7.i386:/usr/share/themes > > This one is due to the fact that Openbox places themes > into /usr/share/themes; so it owns the theme folders it creates; but not > the parent. Should I add this ownership to the spec file and remove the > requirement? (Right now, this directory is provided by either > gtk2-engines and metacity.) add your input to bug #239246 and wait till it's resolved Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Fri May 18 09:56:36 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 18 May 2007 11:56:36 +0200 Subject: packages that could need ExclusiveArch updated In-Reply-To: <200705181010.55936.ville.skytta@iki.fi> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <20070518012540.GA10019@nostromo.devel.redhat.com> <20070518015304.GA4496@neu.nirvana> <200705181010.55936.ville.skytta@iki.fi> Message-ID: <20070518095636.GE9994@neu.nirvana> On Fri, May 18, 2007 at 10:10:55AM +0300, Ville Skytt? wrote: > On Friday 18 May 2007, Axel Thimm wrote: > > On Thu, May 17, 2007 at 09:25:40PM -0400, Bill Nottingham wrote: > > > > > > - *sensors* is 'whatever arches lm-sensors exists on' - probably x86_64 > > > %{ix86} > > > > And ppc. > > Not in my current CVS working dir, but alpha is there: > > $ grep Arch: lm_sensors.spec > ExclusiveArch: alpha %{ix86} x86_64 I was talking about upstream. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Fri May 18 11:39:36 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 18 May 2007 13:39:36 +0200 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <20070517221455.36bb2ac4.bugs.michael@gmx.net> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> <20070517221455.36bb2ac4.bugs.michael@gmx.net> Message-ID: <20070518113936.GD21325@ryvius.pekin.waw.pl> On Thursday, 17 May 2007 at 22:14, Michael Schwendt wrote: > On Tue, 9 Jan 2007 21:06:22 +0100, Michael Schwendt wrote: > > > This is just a reminder. > > > > These are all non-explicit package conflicts found in FE development. > > I've filed several tickets plus a few more for FE<=6 (check out the > > FE7Target bug) long ago. > > Still present in Rawhide 20070517 are: > > clearsilver - 0.10.4-3.fc7.i386 > File conflict with: csound - 5.03.0-13.fc7.i386 > /usr/bin/cs > > csound - 5.03.0-13.fc7.i386 > File conflict with: clearsilver - 0.10.4-3.fc7.i386 > /usr/bin/cs > File conflict with: html-xml-utils - 3.7-4.fc6.i386 > /usr/bin/extract > File conflict with: libextractor - 0.5.17a-1.fc7.i386 > /usr/bin/extract > > cyrus-imapd - 2.3.8-3.fc7.i386 > File conflict with: uw-imap - 2006h-1.fc7.i386 > /etc/pam.d/imap > /etc/pam.d/pop > /usr/share/man/man8/imapd.8.gz > > fish - 1.21.12-1.fc6.i386 > File conflict with: html-xml-utils - 3.7-4.fc6.i386 > /usr/bin/count > /usr/share/man/man1/count.1.gz > > html-xml-utils - 3.7-4.fc6.i386 > File conflict with: csound - 5.03.0-13.fc7.i386 > /usr/bin/extract > File conflict with: fish - 1.21.12-1.fc6.i386 > /usr/bin/count > /usr/share/man/man1/count.1.gz > File conflict with: libextractor - 0.5.17a-1.fc7.i386 > /usr/bin/extract > > libextractor - 0.5.17a-1.fc7.i386 > File conflict with: csound - 5.03.0-13.fc7.i386 > /usr/bin/extract > File conflict with: html-xml-utils - 3.7-4.fc6.i386 > /usr/bin/extract Maintainers of the above should probably work among themselves and with respective upstreams to get those renamed. > plib-devel - 1.8.4-8.fc6.i386 > File conflict with: plib16-devel - 1.6.0-6.fc6.i386 > /usr/include/plib/fnt.h > /usr/include/plib/js.h > /usr/include/plib/netBuffer.h > /usr/include/plib/netChannel.h > /usr/include/plib/netMessage.h > /usr/include/plib/netMonitor.h > /usr/include/plib/netSocket.h > /usr/include/plib/pu.h > /usr/include/plib/sg.h > /usr/include/plib/sl.h > /usr/include/plib/slPortability.h > /usr/include/plib/sm.h > /usr/include/plib/ssg.h > /usr/include/plib/ssgAux.h > /usr/include/plib/ssgKeyFlier.h > /usr/include/plib/ssgaWaveSystem.h > /usr/include/plib/ssgconf.h > /usr/include/plib/ul.h > /usr/include/plib/ulRTTI.h > > plib16-devel - 1.6.0-6.fc6.i386 > File conflict with: plib-devel - 1.8.4-8.fc6.i386 > /usr/include/plib/fnt.h > /usr/include/plib/js.h > /usr/include/plib/netBuffer.h > /usr/include/plib/netChannel.h > /usr/include/plib/netMessage.h > /usr/include/plib/netMonitor.h > /usr/include/plib/netSocket.h > /usr/include/plib/pu.h > /usr/include/plib/sg.h > /usr/include/plib/sl.h > /usr/include/plib/slPortability.h > /usr/include/plib/sm.h > /usr/include/plib/ssg.h > /usr/include/plib/ssgAux.h > /usr/include/plib/ssgKeyFlier.h > /usr/include/plib/ssgaWaveSystem.h > /usr/include/plib/ssgconf.h > /usr/include/plib/ul.h > /usr/include/plib/ulRTTI.h plib16-devel should probably have an explicit conflict with plib-devel. > uw-imap - 2006h-1.fc7.i386 > File conflict with: cyrus-imapd - 2.3.8-3.fc7.i386 > /etc/pam.d/imap > /etc/pam.d/pop > /usr/share/man/man8/imapd.8.gz Could this one be handled by alternatives? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rc040203 at freenet.de Fri May 18 11:59:50 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 13:59:50 +0200 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <20070518113936.GD21325@ryvius.pekin.waw.pl> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> <20070517221455.36bb2ac4.bugs.michael@gmx.net> <20070518113936.GD21325@ryvius.pekin.waw.pl> Message-ID: <1179489591.4735.929.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 13:39 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 17 May 2007 at 22:14, Michael Schwendt wrote: > > On Tue, 9 Jan 2007 21:06:22 +0100, Michael Schwendt wrote: > > > > > This is just a reminder. > > > > > > These are all non-explicit package conflicts found in FE development. > > > I've filed several tickets plus a few more for FE<=6 (check out the > > > FE7Target bug) long ago. > > plib-devel - 1.8.4-8.fc6.i386 > > File conflict with: plib16-devel - 1.6.0-6.fc6.i386 > > /usr/include/plib/fnt.h > > /usr/include/plib/js.h > > /usr/include/plib/netBuffer.h > > /usr/include/plib/netChannel.h > > /usr/include/plib/netMessage.h > > /usr/include/plib/netMonitor.h > > /usr/include/plib/netSocket.h > > /usr/include/plib/pu.h > > /usr/include/plib/sg.h > > /usr/include/plib/sl.h > > /usr/include/plib/slPortability.h > > /usr/include/plib/sm.h > > /usr/include/plib/ssg.h > > /usr/include/plib/ssgAux.h > > /usr/include/plib/ssgKeyFlier.h > > /usr/include/plib/ssgaWaveSystem.h > > /usr/include/plib/ssgconf.h > > /usr/include/plib/ul.h > > /usr/include/plib/ulRTTI.h > > > > plib16-devel - 1.6.0-6.fc6.i386 > > File conflict with: plib-devel - 1.8.4-8.fc6.i386 > > /usr/include/plib/fnt.h > > /usr/include/plib/js.h > > /usr/include/plib/netBuffer.h > > /usr/include/plib/netChannel.h > > /usr/include/plib/netMessage.h > > /usr/include/plib/netMonitor.h > > /usr/include/plib/netSocket.h > > /usr/include/plib/pu.h > > /usr/include/plib/sg.h > > /usr/include/plib/sl.h > > /usr/include/plib/slPortability.h > > /usr/include/plib/sm.h > > /usr/include/plib/ssg.h > > /usr/include/plib/ssgAux.h > > /usr/include/plib/ssgKeyFlier.h > > /usr/include/plib/ssgaWaveSystem.h > > /usr/include/plib/ssgconf.h > > /usr/include/plib/ul.h > > /usr/include/plib/ulRTTI.h > > plib16-devel should probably have an explicit conflict with plib-devel. A better approach would be to let one of the packages should install its headers into a different directory. Ralf From dwalsh at redhat.com Fri May 18 12:05:09 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 May 2007 08:05:09 -0400 Subject: Please tag Fixed in selinux-policy-2.6.4-6 for f7-final In-Reply-To: <1179442699.4787.44.camel@cookie.hadess.net> References: <464C9C3A.1010307@redhat.com> <1179442699.4787.44.camel@cookie.hadess.net> Message-ID: <464D9675.5080106@redhat.com> Bastien Nocera wrote: > On Thu, 2007-05-17 at 14:17 -0400, Daniel J Walsh wrote: > >> Many fixes to make suspend/resume work properly. Jeremy has verified >> changes. >> > > Tagging requests are supposed to go to rel-eng at fedoraproject.org IIRC > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > I know. I am sorry. I screwed up. :^( From j.w.r.degoede at hhs.nl Fri May 18 12:32:13 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 May 2007 14:32:13 +0200 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <1179489591.4735.929.camel@mccallum.corsepiu.local> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> <20070517221455.36bb2ac4.bugs.michael@gmx.net> <20070518113936.GD21325@ryvius.pekin.waw.pl> <1179489591.4735.929.camel@mccallum.corsepiu.local> Message-ID: <464D9CCD.6070108@hhs.nl> Ralf Corsepius wrote: > On Fri, 2007-05-18 at 13:39 +0200, Dominik 'Rathann' Mierzejewski wrote: >> On Thursday, 17 May 2007 at 22:14, Michael Schwendt wrote: >>> On Tue, 9 Jan 2007 21:06:22 +0100, Michael Schwendt wrote: >>> >>>> This is just a reminder. >>>> >>>> These are all non-explicit package conflicts found in FE development. >>>> I've filed several tickets plus a few more for FE<=6 (check out the >>>> FE7Target bug) long ago. > >>> plib-devel - 1.8.4-8.fc6.i386 >>> File conflict with: plib16-devel - 1.6.0-6.fc6.i386 >>> /usr/include/plib/fnt.h >>> /usr/include/plib/js.h >>> /usr/include/plib/netBuffer.h >>> /usr/include/plib/netChannel.h >>> /usr/include/plib/netMessage.h >>> /usr/include/plib/netMonitor.h >>> /usr/include/plib/netSocket.h >>> /usr/include/plib/pu.h >>> /usr/include/plib/sg.h >>> /usr/include/plib/sl.h >>> /usr/include/plib/slPortability.h >>> /usr/include/plib/sm.h >>> /usr/include/plib/ssg.h >>> /usr/include/plib/ssgAux.h >>> /usr/include/plib/ssgKeyFlier.h >>> /usr/include/plib/ssgaWaveSystem.h >>> /usr/include/plib/ssgconf.h >>> /usr/include/plib/ul.h >>> /usr/include/plib/ulRTTI.h >>> >>> plib16-devel - 1.6.0-6.fc6.i386 >>> File conflict with: plib-devel - 1.8.4-8.fc6.i386 >>> /usr/include/plib/fnt.h >>> /usr/include/plib/js.h >>> /usr/include/plib/netBuffer.h >>> /usr/include/plib/netChannel.h >>> /usr/include/plib/netMessage.h >>> /usr/include/plib/netMonitor.h >>> /usr/include/plib/netSocket.h >>> /usr/include/plib/pu.h >>> /usr/include/plib/sg.h >>> /usr/include/plib/sl.h >>> /usr/include/plib/slPortability.h >>> /usr/include/plib/sm.h >>> /usr/include/plib/ssg.h >>> /usr/include/plib/ssgAux.h >>> /usr/include/plib/ssgKeyFlier.h >>> /usr/include/plib/ssgaWaveSystem.h >>> /usr/include/plib/ssgconf.h >>> /usr/include/plib/ul.h >>> /usr/include/plib/ulRTTI.h >> plib16-devel should probably have an explicit conflict with plib-devel. > A better approach would be to let one of the packages should install its > headers into a different directory. > Last time I talked about this with Matthias (the plib16 maintainer, I'm the plib maintainer), we came to the conclusion that there are no packages BuildRequiring plib16, and that it could be orphaned, so I guess that that is the real solution. Matthias? Regards, Hans From dominik at greysector.net Fri May 18 12:17:59 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 18 May 2007 14:17:59 +0200 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <1179489591.4735.929.camel@mccallum.corsepiu.local> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> <20070517221455.36bb2ac4.bugs.michael@gmx.net> <20070518113936.GD21325@ryvius.pekin.waw.pl> <1179489591.4735.929.camel@mccallum.corsepiu.local> Message-ID: <20070518121759.GA21710@ryvius.pekin.waw.pl> On Friday, 18 May 2007 at 13:59, Ralf Corsepius wrote: > On Fri, 2007-05-18 at 13:39 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 17 May 2007 at 22:14, Michael Schwendt wrote: > > > On Tue, 9 Jan 2007 21:06:22 +0100, Michael Schwendt wrote: > > > > > > > This is just a reminder. > > > > > > > > These are all non-explicit package conflicts found in FE development. > > > > I've filed several tickets plus a few more for FE<=6 (check out the > > > > FE7Target bug) long ago. > > > > plib-devel - 1.8.4-8.fc6.i386 > > > File conflict with: plib16-devel - 1.6.0-6.fc6.i386 > > > /usr/include/plib/fnt.h > > > /usr/include/plib/js.h > > > /usr/include/plib/netBuffer.h > > > /usr/include/plib/netChannel.h > > > /usr/include/plib/netMessage.h > > > /usr/include/plib/netMonitor.h > > > /usr/include/plib/netSocket.h > > > /usr/include/plib/pu.h > > > /usr/include/plib/sg.h > > > /usr/include/plib/sl.h > > > /usr/include/plib/slPortability.h > > > /usr/include/plib/sm.h > > > /usr/include/plib/ssg.h > > > /usr/include/plib/ssgAux.h > > > /usr/include/plib/ssgKeyFlier.h > > > /usr/include/plib/ssgaWaveSystem.h > > > /usr/include/plib/ssgconf.h > > > /usr/include/plib/ul.h > > > /usr/include/plib/ulRTTI.h > > > > > > plib16-devel - 1.6.0-6.fc6.i386 > > > File conflict with: plib-devel - 1.8.4-8.fc6.i386 > > > /usr/include/plib/fnt.h > > > /usr/include/plib/js.h > > > /usr/include/plib/netBuffer.h > > > /usr/include/plib/netChannel.h > > > /usr/include/plib/netMessage.h > > > /usr/include/plib/netMonitor.h > > > /usr/include/plib/netSocket.h > > > /usr/include/plib/pu.h > > > /usr/include/plib/sg.h > > > /usr/include/plib/sl.h > > > /usr/include/plib/slPortability.h > > > /usr/include/plib/sm.h > > > /usr/include/plib/ssg.h > > > /usr/include/plib/ssgAux.h > > > /usr/include/plib/ssgKeyFlier.h > > > /usr/include/plib/ssgaWaveSystem.h > > > /usr/include/plib/ssgconf.h > > > /usr/include/plib/ul.h > > > /usr/include/plib/ulRTTI.h > > > > plib16-devel should probably have an explicit conflict with plib-devel. > A better approach would be to let one of the packages should install its > headers into a different directory. Ah, of course! s,/usr/include/plib,/usr/include/plib16,g Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From opensource at till.name Fri May 18 12:34:23 2007 From: opensource at till.name (Till Maas) Date: Fri, 18 May 2007 14:34:23 +0200 Subject: Mentioning FE-NEW in Fedora Extras Review Request submission form Message-ID: <200705181434.24875.opensource@till.name> Aloas, the Bugzilla form for Fedora Extras Review Requests still mentions FE-NEW: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&format=extras-review I don't know, who can change this, so I am writing to this list. Regards, Till From rc040203 at freenet.de Fri May 18 12:39:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 14:39:38 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <200705171320.09402.jkeating@redhat.com> References: <200705141710.20460.jkeating@redhat.com> <200705171153.05559.jkeating@redhat.com> <1179422203.4735.861.camel@mccallum.corsepiu.local> <200705171320.09402.jkeating@redhat.com> Message-ID: <1179491978.4735.930.camel@mccallum.corsepiu.local> On Thu, 2007-05-17 at 13:20 -0400, Jesse Keating wrote: > On Thursday 17 May 2007 13:16:43 Ralf Corsepius wrote: > > Well, you have prematurely deployed an immature product while the > > service personnel is non-reachable. In the commercial world you'd > > probably be sued for this. > > Ralf, where do you see Bodhi deployed? I see koji deployed and I see you forcing us to use it. Ralf From jkeating at redhat.com Fri May 18 13:14:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 09:14:31 -0400 Subject: CVS Branched for Fedora 7 Message-ID: <200705180914.31500.jkeating@redhat.com> And as such, Fedora 7 has entered a deep freeze state. We'll only be accepting release blocker fixes now. http://fedoraproject.org/wiki/QA/ReleaseCriteria https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FC7Blocker -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 13:17:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 09:17:09 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179465300.4735.903.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179238326.3084.64.camel@zod.rchland.ibm.com> <1179465300.4735.903.camel@mccallum.corsepiu.local> Message-ID: <200705180917.09573.jkeating@redhat.com> On Friday 18 May 2007 01:15:00 Ralf Corsepius wrote: > No man-page, There is a README in the package, not great, but a start. > no docs on .koji (--nowait), no docs/man on koji.conf, no > reasonable error messages if koji fails (It did several times because > some servers were inaccessible) isn't setup correctly locally > (/usr/bin/fedora-packager-setup.sh wasn't mentioned anywhere until > somebody fixed it recently - Other people also complained about this). Ok, these are reasonable things to start creating docs for. Would you like to help (by identifying what things you'd be looking for in said docs. I'm horrible at creating docs out of thin air) > > > now also seem to have inconsistencies been rawhide and the buildsystem. > > > Yesterday, I was facing packages which built in rawhide but failed in > > > the buildsystem). > > > > Which and how did they fail? > > perl-modules built flawlessly in a local fc7-mock ("make mock"), but > failed in koji ("make build"). That's not helpful. You have logs, why don't they build right? What were the build IDs? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 13:19:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 09:19:10 -0400 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179491978.4735.930.camel@mccallum.corsepiu.local> References: <200705141710.20460.jkeating@redhat.com> <200705171320.09402.jkeating@redhat.com> <1179491978.4735.930.camel@mccallum.corsepiu.local> Message-ID: <200705180919.10395.jkeating@redhat.com> On Friday 18 May 2007 08:39:38 Ralf Corsepius wrote: > > Ralf, where do you see Bodhi deployed? > > I see koji deployed and I see you forcing us to use it. Nice topic shift there. Lets try to keep your complaints in order ok? Should we start a ralf-complaint-list for proper threading/tracking/archiving ? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Fri May 18 13:23:34 2007 From: jima at beer.tclug.org (Jima) Date: Fri, 18 May 2007 08:23:34 -0500 (CDT) Subject: CVS Branched for Fedora 7 In-Reply-To: <200705180914.31500.jkeating@redhat.com> References: <200705180914.31500.jkeating@redhat.com> Message-ID: On Fri, 18 May 2007, Jesse Keating wrote: > And as such, Fedora 7 has entered a deep freeze state. We'll only be > accepting release blocker fixes now. Woo hoo! Thanks to whoever did the branching. So, we can start goofing off in devel/ again? :-) Jima From rc040203 at freenet.de Fri May 18 13:40:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 15:40:06 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705180917.09573.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179238326.3084.64.camel@zod.rchland.ibm.com> <1179465300.4735.903.camel@mccallum.corsepiu.local> <200705180917.09573.jkeating@redhat.com> Message-ID: <1179495606.4735.960.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 09:17 -0400, Jesse Keating wrote: > On Friday 18 May 2007 01:15:00 Ralf Corsepius wrote: > > No man-page, > > There is a README in the package, not great, but a start. May-be helpful when being familiar with koji, but right now, what's really urgently missing is a "Getting started with koji and Fedora" and "Getting started with koji for plague users". Also, IMO, --nowait should be made default. Not using it is really nagging (I only knew about it, because somebody else already had complained and you had mentioned it some time last week). > > no docs on .koji (--nowait), no docs/man on koji.conf, no > > reasonable error messages if koji fails (It did several times because > > some servers were inaccessible) isn't setup correctly locally > > (/usr/bin/fedora-packager-setup.sh wasn't mentioned anywhere until > > somebody fixed it recently - Other people also complained about this). > > Ok, these are reasonable things to start creating docs for. Would you like to > help (by identifying what things you'd be looking for in said docs. I'm > horrible at creating docs out of thin air) > > > > now also seem to have inconsistencies been rawhide and the buildsystem. > > > > Yesterday, I was facing packages which built in rawhide but failed in > > > > the buildsystem). > > > > > > Which and how did they fail? > > > > perl-modules built flawlessly in a local fc7-mock ("make mock"), but > > failed in koji ("make build"). > > That's not helpful. You have logs, No, because koji doesn't email build results (another regression in comparison to plague - These emails are very useful because they can be archived.). This is the koji entry documenting the breakdown http://koji.fedoraproject.org/koji/buildinfo?buildID=6550 A "make mock" in "devel" on FC6 issued ca. 10-20 mins before the breakdown (with the exact sources as above) did not exhibit anything. > why don't they build right? The origin was a missing "BR: perl(..." (fixed in *-2), an oversight on my part mine, I didn't notice in advance, because "make mock" did exhibit the issue. The only explanation I have is an inconsistency between "koji's repo" and "rawhide" probably related to the perl package. Ralf From jkeating at redhat.com Fri May 18 13:48:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 09:48:26 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179495606.4735.960.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> Message-ID: <200705180948.26750.jkeating@redhat.com> On Friday 18 May 2007 09:40:06 Ralf Corsepius wrote: > > There is a README in the package, not great, but a start. > > May-be helpful when being familiar with koji, but right now, what's > really urgently missing is a "Getting started with koji and Fedora" > and "Getting started with koji for plague users". A couple wiki pages were posted for FAQ like things, which is a great opportunity for you to ask the questions you need answered so that we can document it. > Also, IMO, --nowait should be made default. Not using it is really > nagging (I only knew about it, because somebody else already had > complained and you had mentioned it some time last week). The reason it isn't made default is that there is no converse of it, IE --wait. So by making it not default it gives users the opportunity to either use it if they like, or add a --nowait flag to disable it. One can't have it disabled by default and force a way to have it actually wait. > > > perl-modules built flawlessly in a local fc7-mock ("make mock"), but > > > failed in koji ("make build"). > > > > That's not helpful. You have logs, > > No, because koji doesn't email build results (another regression in > comparison to plague - These emails are very useful because they can be > archived.). Hrm, Koji emails the owner of the package being built by default. It goes to @fedoraproject.org. Are you not getting mail sent to the address you have configured in your Fedora Account ? > This is the koji entry documenting the breakdown > http://koji.fedoraproject.org/koji/buildinfo?buildID=6550 > > A "make mock" in "devel" on FC6 issued ca. 10-20 mins before the > breakdown (with the exact sources as above) did not exhibit anything. > > > ?why don't they build right? > > The origin was a missing "BR: perl(..." (fixed in *-2), an oversight on > my part mine, I didn't notice in advance, because "make mock" did > exhibit the issue. > > The only explanation I have is an inconsistency between "koji's repo" > and "rawhide" probably related to the perl package. Yes, that can happen. Builds happen during the day which alter the buildroot and drift from the previous night's rawhide. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 18 14:00:48 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 18 May 2007 16:00:48 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages Message-ID: <20070518160048.26b06d58@python3.es.egwn.lan> Hi, Koji was unable to rebuild iwlwifi-firmware-2.14.3 : http://koji.fedoraproject.org/koji/taskinfo?taskID=10259 pg.DatabaseError: error 'ERROR: duplicate key violates unique constraint "rpminfo_unique_nvra" ' in 'INSERT INTO rpminfo (name,version,release,epoch, build_id,arch,buildtime,buildroot_id, size,payloadhash) VALUES ('iwlwifi-firmware','2.14.3','1',NULL, 6737,'noarch',1179496397,2855, 69678,'e8d027c0265283cbf18ff82f29bca346') ' My guess is that it koji doesn't work with the "hack" which consists of explicitly listing the relevant archs for a noarch package in order to get it pushed out only for those archs. What should I do here? - The package should be noarch (the same for i386 and x86_64) - The package shouldn't appear for ppc or ppc64 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.77 0.47 0.51 From jkeating at redhat.com Fri May 18 14:03:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 10:03:53 -0400 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518160048.26b06d58@python3.es.egwn.lan> References: <20070518160048.26b06d58@python3.es.egwn.lan> Message-ID: <200705181003.53574.jkeating@redhat.com> On Friday 18 May 2007 10:00:48 Matthias Saou wrote: > My guess is that it koji doesn't work with the "hack" which consists of > explicitly listing the relevant archs for a noarch package in order to > get it pushed out only for those archs. > > What should I do here? > - The package should be noarch (the same for i386 and x86_64) > - The package shouldn't appear for ppc or ppc64 Try ExclusiveArch i386 x86_64, leaving out noarch. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri May 18 14:13:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 16:13:27 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705180948.26750.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> Message-ID: <1179497607.4735.982.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 09:48 -0400, Jesse Keating wrote: > On Friday 18 May 2007 09:40:06 Ralf Corsepius wrote: > > > There is a README in the package, not great, but a start. > > > > May-be helpful when being familiar with koji, but right now, what's > > really urgently missing is a "Getting started with koji and Fedora" > > and "Getting started with koji for plague users". > > A couple wiki pages were posted for FAQ like things, Yes, in recent days the situation has somewhat improved ... > > Also, IMO, --nowait should be made default. Not using it is really > > nagging (I only knew about it, because somebody else already had > > complained and you had mentioned it some time last week). > > The reason it isn't made default is that there is no converse of it, IMO: bug. > IE --wait. So by making it not default it gives users the opportunity to > either use it if they like, or add a --nowait flag to disable it. One can't > have it disabled by default and force a way to have it actually wait. > > > > perl-modules built flawlessly in a local fc7-mock ("make mock"), but > > > > failed in koji ("make build"). > > > > > > That's not helpful. You have logs, > > > > No, because koji doesn't email build results (another regression in > > comparison to plague - These emails are very useful because they can be > > archived.). > > Hrm, Koji emails the owner of the package being built by default. Does it? ... hmm, I have one koji mail in my local buildsys archive, but I can't find any on perl-File-Copy-Recursive? I recall me having dug through koji.fedoraproject.org (Even this isn't mentioned anywhere inside of the koji package) to find out what might have happened to the build. > > This is the koji entry documenting the breakdown > > http://koji.fedoraproject.org/koji/buildinfo?buildID=6550 > > > > A "make mock" in "devel" on FC6 issued ca. 10-20 mins before the > > breakdown (with the exact sources as above) did not exhibit anything. > > > > > why don't they build right? > > > > The origin was a missing "BR: perl(..." (fixed in *-2), an oversight on > > my part mine, I didn't notice in advance, because "make mock" did > > exhibit the issue. > > > > The only explanation I have is an inconsistency between "koji's repo" > > and "rawhide" probably related to the perl package. > > Yes, that can happen. Builds happen during the day which alter the buildroot > and drift from the previous night's rawhide. :( BTW: Invoking http://koji.fedoraproject.org/koji/buildinfo just returned this: Mod_python error: "PythonHandler mod_python.publisher" Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 213, in handler published = publish_object(req, object) File "/usr/lib/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File "/usr/lib/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data return object(**args) TypeError: buildinfo() takes exactly 2 non-keyword arguments (1 given) Ralf From dominik at greysector.net Fri May 18 14:13:43 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 18 May 2007 16:13:43 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705180948.26750.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> Message-ID: <20070518141343.GA22296@ryvius.pekin.waw.pl> On Friday, 18 May 2007 at 15:48, Jesse Keating wrote: > On Friday 18 May 2007 09:40:06 Ralf Corsepius wrote: [...] > > Also, IMO, --nowait should be made default. Not using it is really > > nagging (I only knew about it, because somebody else already had > > complained and you had mentioned it some time last week). > > The reason it isn't made default is that there is no converse of it, > IE --wait. So by making it not default it gives users the opportunity to > either use it if they like, or add a --nowait flag to disable it. One can't > have it disabled by default and force a way to have it actually wait. Well, that's a regression compared to plague. Please fix it (or do I have to file a bug against koji to have it done?). I agree with Ralf that koji should mimic plague behaviour in that respect. > > > > perl-modules built flawlessly in a local fc7-mock ("make mock"), but > > > > failed in koji ("make build"). > > > > > > That's not helpful. You have logs, > > > > No, because koji doesn't email build results (another regression in > > comparison to plague - These emails are very useful because they can be > > archived.). > > Hrm, Koji emails the owner of the package being built by default. It goes to > @fedoraproject.org. Are you not getting mail sent to the address > you have configured in your Fedora Account ? Now that you mentioned it, I'm not getting those either. In fact, I didn't even know there *were* @fedoraproject.org accounts for all contributors. Is it documented somewhere? FWIW, plague reports still reach me. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From giallu at gmail.com Fri May 18 14:19:35 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 18 May 2007 16:19:35 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <20070518141343.GA22296@ryvius.pekin.waw.pl> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> Message-ID: On 5/18/07, Dominik 'Rathann' Mierzejewski wrote: > Now that you mentioned it, I'm not getting those either. In fact, I didn't > even know there *were* @fedoraproject.org accounts for all > contributors. Is it documented somewhere? eh. I also discovered that only a few weeks ago... From mclasen at redhat.com Fri May 18 14:20:37 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 18 May 2007 10:20:37 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <20070518141343.GA22296@ryvius.pekin.waw.pl> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> Message-ID: <1179498037.3807.6.camel@localhost.localdomain> On Fri, 2007-05-18 at 16:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > > The reason it isn't made default is that there is no converse of it, > > IE --wait. So by making it not default it gives users the opportunity to > > either use it if they like, or add a --nowait flag to disable it. One can't > > have it disabled by default and force a way to have it actually wait. > > Well, that's a regression compared to plague. Please fix it (or do I have > to file a bug against koji to have it done?). I agree with Ralf that koji > should mimic plague behaviour in that respect. I'm sure there are a lot of people who would respond with saying that koji should mimic brew behaviour instead, i.e. stay as it is now. To make all the picky developers happy, we probably need a full set of --wait/--nowait options plus a config file to set the default. The build system is open source now, so everybody can write patches... From rc040203 at freenet.de Fri May 18 14:30:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 16:30:22 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179498037.3807.6.camel@localhost.localdomain> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> <1179498037.3807.6.camel@localhost.localdomain> Message-ID: <1179498623.4735.991.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 10:20 -0400, Matthias Clasen wrote: > On Fri, 2007-05-18 at 16:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > The reason it isn't made default is that there is no converse of it, > > > IE --wait. So by making it not default it gives users the opportunity to > > > either use it if they like, or add a --nowait flag to disable it. One can't > > > have it disabled by default and force a way to have it actually wait. > > > > Well, that's a regression compared to plague. Please fix it (or do I have > > to file a bug against koji to have it done?). I agree with Ralf that koji > > should mimic plague behaviour in that respect. > > I'm sure there are a lot of people who would respond with saying that koji should > mimic brew behaviour instead, i.e. stay as it is now. brew == redhat internal stuff. plague == externally used stuff. Did you ever consider that there might be users who work over low bandwidth lines and/or don't want to wait for hours until the buildsys returns? IMO, "launching build jobs" is an example of a classical batch task. "launch", forget about it until some feedback is returned (email). > To make all the > picky developers happy, we probably need a full set of --wait/--nowait > options plus a config file to set the default. Is there any config file? ... no docs. > The build system is open > source now, so everybody can write patches... May-be if she speaks python ... I don't. Ralf From dominik at greysector.net Fri May 18 14:32:23 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 18 May 2007 16:32:23 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179498037.3807.6.camel@localhost.localdomain> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> <1179498037.3807.6.camel@localhost.localdomain> Message-ID: <20070518143223.GB22777@ryvius.pekin.waw.pl> On Friday, 18 May 2007 at 16:20, Matthias Clasen wrote: > On Fri, 2007-05-18 at 16:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > The reason it isn't made default is that there is no converse of it, > > > IE --wait. So by making it not default it gives users the opportunity to > > > either use it if they like, or add a --nowait flag to disable it. One can't > > > have it disabled by default and force a way to have it actually wait. > > > > Well, that's a regression compared to plague. Please fix it (or do I have > > to file a bug against koji to have it done?). I agree with Ralf that koji > > should mimic plague behaviour in that respect. > > I'm sure there are a lot of people who would respond with saying that koji should > mimic brew behaviour instead, i.e. stay as it is now. To make all the > picky developers happy, we probably need a full set of --wait/--nowait > options plus a config file to set the default. The build system is open > source now, so everybody can write patches... I'm pretty sure there are more Extras contributors than Core. The system may be open-source, but not everyone speaks Python and the system has been forced upon us "packaging monkeys" (as some people like to call us). Could it at least NOT introduce radical changes in workflow, please? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Fedora at FamilleCollet.com Fri May 18 14:35:18 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 18 May 2007 16:35:18 +0200 Subject: CVS Branched for Fedora 7 In-Reply-To: References: <200705180914.31500.jkeating@redhat.com> Message-ID: <464DB9A6.4090809@FamilleCollet.com> Jima a ?crit : > Woo hoo! Thanks to whoever did the branching. > So, we can start goofing off in devel/ again? :-) It seems that no : $ make build usage: koji build [options] target URL (Specify the --help global option for a list of other help options) koji: error: Unknown build target: dist-f8 make: *** [koji] Erreur 1 Remi. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 18 14:36:27 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 18 May 2007 16:36:27 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <200705181003.53574.jkeating@redhat.com> References: <20070518160048.26b06d58@python3.es.egwn.lan> <200705181003.53574.jkeating@redhat.com> Message-ID: <20070518163627.57058738@python3.es.egwn.lan> Jesse Keating wrote : > On Friday 18 May 2007 10:00:48 Matthias Saou wrote: > > My guess is that it koji doesn't work with the "hack" which consists of > > explicitly listing the relevant archs for a noarch package in order to > > get it pushed out only for those archs. > > > > What should I do here? > > - The package should be noarch (the same for i386 and x86_64) > > - The package shouldn't appear for ppc or ppc64 > > Try ExclusiveArch i386 x86_64, leaving out noarch. OK, I'll try, but IIRC that used to make plague fail, because the arch it was going to build for (noarch) wasn't included in the exclusive archs ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.69 0.51 0.47 From jwboyer at jdub.homelinux.org Fri May 18 14:35:19 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 18 May 2007 09:35:19 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <20070518143223.GB22777@ryvius.pekin.waw.pl> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> <1179498037.3807.6.camel@localhost.localdomain> <20070518143223.GB22777@ryvius.pekin.waw.pl> Message-ID: <1179498919.3046.5.camel@vader.jdub.homelinux.org> On Fri, 2007-05-18 at 16:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 18 May 2007 at 16:20, Matthias Clasen wrote: > > On Fri, 2007-05-18 at 16:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > > > The reason it isn't made default is that there is no converse of it, > > > > IE --wait. So by making it not default it gives users the opportunity to > > > > either use it if they like, or add a --nowait flag to disable it. One can't > > > > have it disabled by default and force a way to have it actually wait. > > > > > > Well, that's a regression compared to plague. Please fix it (or do I have > > > to file a bug against koji to have it done?). I agree with Ralf that koji > > > should mimic plague behaviour in that respect. > > > > I'm sure there are a lot of people who would respond with saying that koji should > > mimic brew behaviour instead, i.e. stay as it is now. To make all the > > picky developers happy, we probably need a full set of --wait/--nowait > > options plus a config file to set the default. The build system is open > > source now, so everybody can write patches... > > I'm pretty sure there are more Extras contributors than Core. The system > may be open-source, but not everyone speaks Python and the system has been > forced upon us "packaging monkeys" (as some people like to call us). > Could it at least NOT introduce radical changes in workflow, please? You're confusing two issues. Koji is simply a build server. It doesn't change workflow (other than perhaps some output and notification options that likely need fixing). What changes workflow is the release policies. josh From jwboyer at jdub.homelinux.org Fri May 18 14:36:29 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 18 May 2007 09:36:29 -0500 Subject: CVS Branched for Fedora 7 In-Reply-To: <464DB9A6.4090809@FamilleCollet.com> References: <200705180914.31500.jkeating@redhat.com> <464DB9A6.4090809@FamilleCollet.com> Message-ID: <1179498989.3046.7.camel@vader.jdub.homelinux.org> On Fri, 2007-05-18 at 16:35 +0200, Remi Collet wrote: > Jima a ?crit : > > Woo hoo! Thanks to whoever did the branching. > > So, we can start goofing off in devel/ again? :-) > > It seems that no : > > $ make build > usage: koji build [options] target URL > (Specify the --help global option for a list of other help options) > > koji: error: Unknown build target: dist-f8 > make: *** [koji] Erreur 1 I think the tag was perhaps not unlocked. Jesse is currently traveling to the office, so I'm sure he can fix it once he gets in. josh From jkeating at redhat.com Fri May 18 14:42:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 10:42:06 -0400 Subject: CVS Branched for Fedora 7 In-Reply-To: <1179498989.3046.7.camel@vader.jdub.homelinux.org> References: <200705180914.31500.jkeating@redhat.com> <464DB9A6.4090809@FamilleCollet.com> <1179498989.3046.7.camel@vader.jdub.homelinux.org> Message-ID: <200705181042.06741.jkeating@redhat.com> On Friday 18 May 2007 10:36:29 Josh Boyer wrote: > > It seems that no : > > > > $ make build > > usage: koji build [options] target URL > > (Specify the --help global option for a list of other help options) > > > > koji: error: Unknown build target: dist-f8 > > make: *** [koji] Erreur 1 > > I think the tag was perhaps not unlocked. ?Jesse is currently traveling > to the office, so I'm sure he can fix it once he gets in. Actually I realized while in the shower that even though I unlocked the dist-f8 tag, I forgot to create the dist-f8 build target that links dist-f8 and dist-f8-build together as a build entity. This has been fixed. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Fri May 18 14:43:07 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 18 May 2007 16:43:07 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179498919.3046.5.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> <1179498037.3807.6.camel@localhost.localdomain> <20070518143223.GB22777@ryvius.pekin.waw.pl> <1179498919.3046.5.camel@vader.jdub.homelinux.org> Message-ID: <20070518144307.GC22777@ryvius.pekin.waw.pl> On Friday, 18 May 2007 at 16:35, Josh Boyer wrote: > On Fri, 2007-05-18 at 16:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 18 May 2007 at 16:20, Matthias Clasen wrote: > > > On Fri, 2007-05-18 at 16:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > > > > > > The reason it isn't made default is that there is no converse of it, > > > > > IE --wait. So by making it not default it gives users the opportunity to > > > > > either use it if they like, or add a --nowait flag to disable it. One can't > > > > > have it disabled by default and force a way to have it actually wait. > > > > > > > > Well, that's a regression compared to plague. Please fix it (or do I have > > > > to file a bug against koji to have it done?). I agree with Ralf that koji > > > > should mimic plague behaviour in that respect. > > > > > > I'm sure there are a lot of people who would respond with saying that koji should > > > mimic brew behaviour instead, i.e. stay as it is now. To make all the > > > picky developers happy, we probably need a full set of --wait/--nowait > > > options plus a config file to set the default. The build system is open > > > source now, so everybody can write patches... > > > > I'm pretty sure there are more Extras contributors than Core. The system > > may be open-source, but not everyone speaks Python and the system has been > > forced upon us "packaging monkeys" (as some people like to call us). > > Could it at least NOT introduce radical changes in workflow, please? > > You're confusing two issues. No, I'm not. > Koji is simply a build server. And client. Just like plague. > It doesn't change workflow (other than perhaps some output and > notification options that likely need fixing). Well the defaults ARE different. That's annoying. That, and the lack of proper documentation. > What changes workflow is the release policies. That's a separate issue. I wonder where those policy changes were discussed, because I only became aware of them after they were announced here. That's *after* the fact, mind you. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rc040203 at freenet.de Fri May 18 14:44:42 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 16:44:42 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179498919.3046.5.camel@vader.jdub.homelinux.org> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> <1179498037.3807.6.camel@localhost.localdomain> <20070518143223.GB22777@ryvius.pekin.waw.pl> <1179498919.3046.5.camel@vader.jdub.homelinux.org> Message-ID: <1179499482.4735.999.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 09:35 -0500, Josh Boyer wrote: > On Fri, 2007-05-18 at 16:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 18 May 2007 at 16:20, Matthias Clasen wrote: > > > On Fri, 2007-05-18 at 16:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > You're confusing two issues. Koji is simply a build server. It doesn't > change workflow (other than perhaps some output and notification options > that likely need fixing). C'mon, it does. "make build" with plague means: "launch", ...(go offline) ... be notified some time (often hours) later .. == batch. "make build" with default options means: "launch", ... wait until "koji" (the client program) returns, stay online during this == interactive. => different workflow. > What changes workflow is the release policies. Yes, ... Ralf From jkeating at redhat.com Fri May 18 14:46:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 10:46:22 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179497607.4735.982.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180948.26750.jkeating@redhat.com> <1179497607.4735.982.camel@mccallum.corsepiu.local> Message-ID: <200705181046.23065.jkeating@redhat.com> On Friday 18 May 2007 10:13:27 Ralf Corsepius wrote: > Does it? ... hmm, I have one koji mail in my local buildsys archive, but > I can't find any on perl-File-Copy-Recursive? > > I recall me having dug through koji.fedoraproject.org (Even this isn't > mentioned anywhere inside of the koji package) to find out what might > have happened to the build. It sends mails on success and failure of the build, to the owner listed for said package. You seem to be listed as the owner, so you should have gotten the mail, unless there is something between koji and you that is blocking the mail from being delivered. > > > This is the koji entry documenting the breakdown > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=6550 > > > > > > A "make mock" in "devel" on FC6 issued ca. 10-20 mins before the > > > breakdown (with the exact sources as above) did not exhibit anything. > > > > > > > ?why don't they build right? > > > > > > The origin was a missing "BR: perl(..." (fixed in *-2), an oversight on > > > my part mine, I didn't notice in advance, because "make mock" did > > > exhibit the issue. > > > > > > The only explanation I have is an inconsistency between "koji's repo" > > > and "rawhide" probably related to the perl package. > > > > Yes, that can happen. ?Builds happen during the day which alter the > > buildroot and drift from the previous night's rawhide. > > > :( > > BTW: Invoking http://koji.fedoraproject.org/koji/buildinfo > just returned this: > > > TypeError: buildinfo() takes exactly 2 non-keyword arguments (1 given) buildinfo takes arguments. You'd typically get to a buildinfo link through something like http://koji.fedoraproject.org/koji/packageinfo?packageID=2934 page which lists a few builds, such as http://koji.fedoraproject.org/koji/buildinfo?buildID=6550 this failed build of perl-File-Copy-Recursive -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri May 18 14:57:55 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 18 May 2007 16:57:55 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705180948.26750.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> Message-ID: <20070518165755.359ba10c.bugs.michael@gmx.net> On Fri, 18 May 2007 09:48:26 -0400, Jesse Keating wrote: > > No, because koji doesn't email build results (another regression in > > comparison to plague - These emails are very useful because they can be > > archived.). > > Hrm, Koji emails the owner of the package being built by default. It goes to > @fedoraproject.org. Are you not getting mail sent to the address > you have configured in your Fedora Account ? Does koji *always* do this by spawning a separate notification task? If so, that one should be in the db somewhere. From j.w.r.degoede at hhs.nl Fri May 18 15:20:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 May 2007 17:20:01 +0200 Subject: Branching done ?? Message-ID: <464DC421.2020903@hhs.nl> Hi all, I just did a CVS update and I did not see any F7 or FC-7 dirs for any of my 139 packages, is this another undocumented unannounced change in workflow, and if so please explain, or did something go wrong with the branching. Regards, Hans From bugs.michael at gmx.net Fri May 18 15:07:10 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 18 May 2007 17:07:10 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518160048.26b06d58@python3.es.egwn.lan> References: <20070518160048.26b06d58@python3.es.egwn.lan> Message-ID: <20070518170710.7e962dbc.bugs.michael@gmx.net> On Fri, 18 May 2007 16:00:48 +0200, Matthias Saou wrote: > Hi, > > Koji was unable to rebuild iwlwifi-firmware-2.14.3 : > > http://koji.fedoraproject.org/koji/taskinfo?taskID=10259 > > pg.DatabaseError: error 'ERROR: duplicate key violates unique > constraint "rpminfo_unique_nvra" ' in 'INSERT INTO rpminfo > (name,version,release,epoch, build_id,arch,buildtime,buildroot_id, > size,payloadhash) > VALUES ('iwlwifi-firmware','2.14.3','1',NULL, > 6737,'noarch',1179496397,2855, > 69678,'e8d027c0265283cbf18ff82f29bca346') > ' > > My guess is that it koji doesn't work with the "hack" which consists of > explicitly listing the relevant archs for a noarch package in order to > get it pushed out only for those archs. > > What should I do here? > - The package should be noarch (the same for i386 and x86_64) > - The package shouldn't appear for ppc or ppc64 Huh, what? :-O BuildArch: noarch ExcludeArch: ... is what you want. Everything else is a false and bad recommendation and has not worked before in plague either. From jwboyer at jdub.homelinux.org Fri May 18 15:08:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 18 May 2007 10:08:59 -0500 Subject: Branching done ?? In-Reply-To: <464DC421.2020903@hhs.nl> References: <464DC421.2020903@hhs.nl> Message-ID: <1179500939.3046.9.camel@vader.jdub.homelinux.org> On Fri, 2007-05-18 at 17:20 +0200, Hans de Goede wrote: > Hi all, > > I just did a CVS update and I did not see any F7 or FC-7 dirs for any of my 139 > packages, is this another undocumented unannounced change in workflow, and if > so please explain, or did something go wrong with the branching. Did you do 'cvs up -dPA' ? josh From jkeating at redhat.com Fri May 18 15:16:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 11:16:02 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <20070518165755.359ba10c.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180948.26750.jkeating@redhat.com> <20070518165755.359ba10c.bugs.michael@gmx.net> Message-ID: <200705181116.02524.jkeating@redhat.com> On Friday 18 May 2007 10:57:55 Michael Schwendt wrote: > Does koji *always* do this by spawning a separate notification task? > If so, that one should be in the db somewhere. AFAIK yes. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri May 18 15:31:41 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 May 2007 17:31:41 +0200 Subject: Branching done ?? In-Reply-To: <1179500939.3046.9.camel@vader.jdub.homelinux.org> References: <464DC421.2020903@hhs.nl> <1179500939.3046.9.camel@vader.jdub.homelinux.org> Message-ID: <464DC6DD.8080402@hhs.nl> Josh Boyer wrote: > On Fri, 2007-05-18 at 17:20 +0200, Hans de Goede wrote: >> Hi all, >> >> I just did a CVS update and I did not see any F7 or FC-7 dirs for any of my 139 >> packages, is this another undocumented unannounced change in workflow, and if >> so please explain, or did something go wrong with the branching. > > Did you do 'cvs up -dPA' ? > Nope, that fixes it, thanks! I used to have -dP in my .cvsrc, but I accidentely deleted that some time ago. However a new package for which the dirs have been created last night (iow shortly before the branch) doesn't have an F-7, the involved package is "ants", the same probably goes for "rott" (which I still have to import) as rott was created at the same time. Regards, Hans From fedora at camperquake.de Fri May 18 15:17:53 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 18 May 2007 17:17:53 +0200 Subject: CVS Branched for Fedora 7 In-Reply-To: <200705181042.06741.jkeating@redhat.com> References: <200705180914.31500.jkeating@redhat.com> <464DB9A6.4090809@FamilleCollet.com> <1179498989.3046.7.camel@vader.jdub.homelinux.org> <200705181042.06741.jkeating@redhat.com> Message-ID: <20070518171753.78099232@banea.int.addix.net> Hi. On Fri, 18 May 2007 10:42:06 -0400, Jesse Keating wrote: > Actually I realized while in the shower that even though I unlocked > the dist-f8 tag, I forgot to create the dist-f8 build target that > links dist-f8 and dist-f8-build together as a build entity. This has > been fixed. Through your shower-integrated terminal, I presume? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 18 15:20:48 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 18 May 2007 17:20:48 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518163627.57058738@python3.es.egwn.lan> References: <20070518160048.26b06d58@python3.es.egwn.lan> <200705181003.53574.jkeating@redhat.com> <20070518163627.57058738@python3.es.egwn.lan> Message-ID: <20070518172048.58264d38@python3.es.egwn.lan> Matthias Saou wrote : > Jesse Keating wrote : > > > On Friday 18 May 2007 10:00:48 Matthias Saou wrote: > > > My guess is that it koji doesn't work with the "hack" which consists of > > > explicitly listing the relevant archs for a noarch package in order to > > > get it pushed out only for those archs. > > > > > > What should I do here? > > > - The package should be noarch (the same for i386 and x86_64) > > > - The package shouldn't appear for ppc or ppc64 > > > > Try ExclusiveArch i386 x86_64, leaving out noarch. > > OK, I'll try, but IIRC that used to make plague fail, because the arch > it was going to build for (noarch) wasn't included in the exclusive > archs ;-) As I feared... and it probably wasn't plague, but mock, refusing to build a package for its "BuildArch:" if it's not contained in "ExclusiveArch:", which does make sense... http://koji.fedoraproject.org/koji/taskinfo?taskID=10271 : "BuildrootError: error building package (arch noarch), mock exited with status 10" Seems like it's no longer possible to make a noarch package only available to certain archs. Any suggestions on how to fix this, or work around it? Some kind of blacklisting inside the compose tool? Fixing Koji to accept the hack? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.55 0.43 0.40 From jwboyer at jdub.homelinux.org Fri May 18 15:20:53 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 18 May 2007 10:20:53 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179499482.4735.999.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> <1179498037.3807.6.camel@localhost.localdomain> <20070518143223.GB22777@ryvius.pekin.waw.pl> <1179498919.3046.5.camel@vader.jdub.homelinux.org> <1179499482.4735.999.camel@mccallum.corsepiu.local> Message-ID: <1179501654.3046.12.camel@vader.jdub.homelinux.org> On Fri, 2007-05-18 at 16:44 +0200, Ralf Corsepius wrote: > On Fri, 2007-05-18 at 09:35 -0500, Josh Boyer wrote: > > On Fri, 2007-05-18 at 16:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > On Friday, 18 May 2007 at 16:20, Matthias Clasen wrote: > > > > On Fri, 2007-05-18 at 16:13 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > You're confusing two issues. Koji is simply a build server. It doesn't > > change workflow (other than perhaps some output and notification options > > that likely need fixing). > C'mon, it does. > > "make build" with plague means: "launch", ...(go offline) ... be > notified some time (often hours) later .. == batch. > > "make build" with default options means: "launch", ... wait until > "koji" (the client program) returns, stay online during this == > interactive. > > => different workflow. I said "(other than perhaps some output and notification options that likely need fixing)". josh From bugs.michael at gmx.net Fri May 18 15:24:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 18 May 2007 17:24:50 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705181116.02524.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180948.26750.jkeating@redhat.com> <20070518165755.359ba10c.bugs.michael@gmx.net> <200705181116.02524.jkeating@redhat.com> Message-ID: <20070518172450.5eaa8d3f.bugs.michael@gmx.net> On Fri, 18 May 2007 11:16:02 -0400, Jesse Keating wrote: > > Does koji *always* do this by spawning a separate notification task? > > If so, that one should be in the db somewhere. > > AFAIK yes. Has koji been fixed yet to handle UTF-8 in Ralf's surname? From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 18 15:23:56 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 18 May 2007 17:23:56 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518170710.7e962dbc.bugs.michael@gmx.net> References: <20070518160048.26b06d58@python3.es.egwn.lan> <20070518170710.7e962dbc.bugs.michael@gmx.net> Message-ID: <20070518172356.0dbe5007@python3.es.egwn.lan> Michael Schwendt wrote : > > My guess is that it koji doesn't work with the "hack" which consists of > > explicitly listing the relevant archs for a noarch package in order to > > get it pushed out only for those archs. > > > > What should I do here? > > - The package should be noarch (the same for i386 and x86_64) > > - The package shouldn't appear for ppc or ppc64 > > Huh, what? :-O > > BuildArch: noarch > ExcludeArch: ... > > is what you want. Everything else is a false and bad recommendation > and has not worked before in plague either. I thought it was the other way around... with ExcludeArch not being present in the source rpm, thus making it impossible for the compose tool to know that the resulting noarch package was only meant to be made available for some archs and not others, and OTOH having ExclusiveArch be passed into the source rpm and used by the compose tool. I'm getting more and more confused :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.23 0.35 0.37 From jkeating at redhat.com Fri May 18 15:23:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 11:23:28 -0400 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518172048.58264d38@python3.es.egwn.lan> References: <20070518160048.26b06d58@python3.es.egwn.lan> <20070518163627.57058738@python3.es.egwn.lan> <20070518172048.58264d38@python3.es.egwn.lan> Message-ID: <200705181123.28984.jkeating@redhat.com> On Friday 18 May 2007 11:20:48 Matthias Saou wrote: > As I feared... and it probably wasn't plague, but mock, refusing to > build a package for its "BuildArch:" if it's not contained in > "ExclusiveArch:", which does make sense... > > http://koji.fedoraproject.org/koji/taskinfo?taskID=10271 : > "BuildrootError: error building package (arch noarch), mock exited with > status 10" > > Seems like it's no longer possible to make a noarch package only > available to certain archs. Any suggestions on how to fix this, or > work around it? Some kind of blacklisting inside the compose tool? > Fixing Koji to accept the hack? Oooh, we use ExcludeArch not ExclusiveArch for that internally, I bet the "hack" just doesn't extend to ExclusiveArch. For now, can you switch to ExcludeArch the arches that won't work, and file a ticket at hosted.fedoraproject.org/projects/koji to look into this? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 15:29:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 11:29:55 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <20070518172450.5eaa8d3f.bugs.michael@gmx.net> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705181116.02524.jkeating@redhat.com> <20070518172450.5eaa8d3f.bugs.michael@gmx.net> Message-ID: <200705181129.56292.jkeating@redhat.com> On Friday 18 May 2007 11:24:50 Michael Schwendt wrote: > Has koji been fixed yet to handle UTF-8 in Ralf's surname? That could be it. Mike? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 15:31:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 11:31:24 -0400 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518172356.0dbe5007@python3.es.egwn.lan> References: <20070518160048.26b06d58@python3.es.egwn.lan> <20070518170710.7e962dbc.bugs.michael@gmx.net> <20070518172356.0dbe5007@python3.es.egwn.lan> Message-ID: <200705181131.25267.jkeating@redhat.com> On Friday 18 May 2007 11:23:56 Matthias Saou wrote: > I thought it was the other way around... with ExcludeArch not being > present in the source rpm, thus making it impossible for the compose > tool to know that the resulting noarch package was only meant to be > made available for some archs and not others, and OTOH having > ExclusiveArch be passed into the source rpm and used by the compose > tool. The compose tool we used internally for Core, and the new tool (mash) we're using for the merged Fedora handle looking at _both_ ExcludeArch and ExclusiveArch settings in the source rpm used to create the noarch package in question. I don't believe Koji handles the ExclusiveArch case though, only the ExcludeArch. (See firstboot for an example) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Fri May 18 15:34:14 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 18 May 2007 17:34:14 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518172356.0dbe5007@python3.es.egwn.lan> References: <20070518160048.26b06d58@python3.es.egwn.lan> <20070518170710.7e962dbc.bugs.michael@gmx.net> <20070518172356.0dbe5007@python3.es.egwn.lan> Message-ID: <20070518173414.08c9e048.bugs.michael@gmx.net> On Fri, 18 May 2007 17:23:56 +0200, Matthias Saou wrote: > Michael Schwendt wrote : > > > > My guess is that it koji doesn't work with the "hack" which consists of > > > explicitly listing the relevant archs for a noarch package in order to > > > get it pushed out only for those archs. > > > > > > What should I do here? > > > - The package should be noarch (the same for i386 and x86_64) > > > - The package shouldn't appear for ppc or ppc64 > > > > Huh, what? :-O > > > > BuildArch: noarch > > ExcludeArch: ... > > > > is what you want. Everything else is a false and bad recommendation > > and has not worked before in plague either. > > I thought it was the other way around... with ExcludeArch not being > present in the source rpm, thus making it impossible for the compose > tool to know that the resulting noarch package was only meant to be > made available for some archs and not others, and OTOH having > ExclusiveArch be passed into the source rpm and used by the compose > tool. > > I'm getting more and more confused :-) > > Matthias The ExclusiveArch tag doesn't make it into the binary rpm, either, certainly not for __noarch__ builds. From j.w.r.degoede at hhs.nl Fri May 18 15:48:35 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 May 2007 17:48:35 +0200 Subject: cvs-import.sh still creates tags ending at fc7 Message-ID: <464DCAD3.7070503@hhs.nl> Hi all, The subject says it all I just imported 2 new packages with cvs-import.sh and it created xxx_fc7 tags in the devel dir of those packages, whereas make tag does do the right thing. And yes my cvs-import.sh is 100% up2date. Regards, Hans From Fedora at FamilleCollet.com Fri May 18 15:40:24 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 18 May 2007 17:40:24 +0200 Subject: CVS Branched for Fedora 7 In-Reply-To: <200705181042.06741.jkeating@redhat.com> References: <200705180914.31500.jkeating@redhat.com> <464DB9A6.4090809@FamilleCollet.com> <1179498989.3046.7.camel@vader.jdub.homelinux.org> <200705181042.06741.jkeating@redhat.com> Message-ID: <464DC8E8.8090800@FamilleCollet.com> Jesse Keating a ?crit : > Actually I realized while in the shower that even though I unlocked the > dist-f8 tag, I forgot to create the dist-f8 build target that links dist-f8 > and dist-f8-build together as a build entity. This has been fixed. Thanks. Now, make build is accepted, but failed. Another idea ? Here is the Koji report : Package: php-pear-Net-Traceroute-0.21.1-2.fc8 Tag: dist-f8 Status: failed Built by: remi ID: 6744 Started: Fri, 18 May 2007 08:25:28 MST Finished: Fri, 18 May 2007 08:28:59 MST Changelog: * Wed May 16 2007 Remi Collet 0.21.1-2 - From review, change description - add Requires: traceroute * Sat May 12 2007 Remi Collet 0.21.1-1 - initial RPM (generated specfile + cleanup) - add CHANGELOG and LICENSE php-pear-Net-Traceroute-0.21.1-2.fc8 (6744) failed on xenbuilder3.fedora.phx.redhat.com (noarch): GenericError: Unable to complete build: release mismatch (build: 2.fc8, rpm: 2.fc7) SRPMS: php-pear-Net-Traceroute-0.21.1-2.fc7.src.rpm php-pear-Net-Traceroute-0.21.1-2.fc8.src.rpm Failed tasks: ------------- Task 10344 on xenbuilder3.fedora.phx.redhat.com Task Type: build (dist-f8, devel:php-pear-Net-Traceroute-0_21_1-2_fc8) Closed tasks: ------------- Task 10361 on xenbuilder1.fedora.redhat.com Task Type: buildArch (php-pear-Net-Traceroute-0.21.1-2.fc8.src.rpm, noarch) logs: http://koji.fedoraproject.org/koji/getfile?taskID=10361&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=10361&name=mockconfig.log http://koji.fedoraproject.org/koji/getfile?taskID=10361&name=root.log rpms: http://koji.fedoraproject.org/koji/getfile?taskID=10361&name=php-pear-Net-Traceroute-0.21.1-2.fc7.noarch.rpm Task 10359 on xenbuilder1.fedora.redhat.com Task Type: buildSRPMFromCVS (devel:php-pear-Net-Traceroute-0_21_1-2_fc8) logs: http://koji.fedoraproject.org/koji/getfile?taskID=10359&name=srpm.log Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10344 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=6744 From mbarnes at redhat.com Fri May 18 15:47:54 2007 From: mbarnes at redhat.com (Matthew Barnes) Date: Fri, 18 May 2007 11:47:54 -0400 Subject: CVS Branched for Fedora 7 In-Reply-To: <464DC8E8.8090800@FamilleCollet.com> References: <200705180914.31500.jkeating@redhat.com> <464DB9A6.4090809@FamilleCollet.com> <1179498989.3046.7.camel@vader.jdub.homelinux.org> <200705181042.06741.jkeating@redhat.com> <464DC8E8.8090800@FamilleCollet.com> Message-ID: <1179503275.24748.19.camel@localhost.localdomain> On Fri, 2007-05-18 at 17:40 +0200, Remi Collet wrote: > php-pear-Net-Traceroute-0.21.1-2.fc8 (6744) failed on > xenbuilder3.fedora.phx.redhat.com (noarch): > GenericError: Unable to complete build: release mismatch (build: > 2.fc8, rpm: 2.fc7) I'm seeing this too. Perhaps a dist tag was not updated somewhere? Matthew Barnes From rc040203 at freenet.de Fri May 18 16:03:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 18:03:15 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705181046.23065.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180948.26750.jkeating@redhat.com> <1179497607.4735.982.camel@mccallum.corsepiu.local> <200705181046.23065.jkeating@redhat.com> Message-ID: <1179504195.4735.1003.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 10:46 -0400, Jesse Keating wrote: > On Friday 18 May 2007 10:13:27 Ralf Corsepius wrote: > > TypeError: buildinfo() takes exactly 2 non-keyword arguments (1 given) > > buildinfo takes arguments. Web author's lesson #1: Any web page which chokes if being invoked with incorrect arguments is broken. Ralf From jkeating at redhat.com Fri May 18 16:14:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 12:14:41 -0400 Subject: buildsys-macros package needs to be rebuilt Message-ID: <200705181214.42065.jkeating@redhat.com> To apply the .fc8 dist tag. Working on it now, some builds will fail, sorry about this. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 16:29:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 12:29:18 -0400 Subject: buildsys-macros package needs to be rebuilt In-Reply-To: <200705181214.42065.jkeating@redhat.com> References: <200705181214.42065.jkeating@redhat.com> Message-ID: <200705181229.19053.jkeating@redhat.com> On Friday 18 May 2007 12:14:41 Jesse Keating wrote: > To apply the .fc8 dist tag. Working on it now, some builds will fail, > sorry about this. Rather redhat-rpm-config. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 16:32:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 12:32:51 -0400 Subject: CVS Branched for Fedora 7 In-Reply-To: <1179503275.24748.19.camel@localhost.localdomain> References: <200705180914.31500.jkeating@redhat.com> <464DC8E8.8090800@FamilleCollet.com> <1179503275.24748.19.camel@localhost.localdomain> Message-ID: <200705181232.52035.jkeating@redhat.com> On Friday 18 May 2007 11:47:54 Matthew Barnes wrote: > I'm seeing this too. ?Perhaps a dist tag was not updated somewhere? I'm working on that. Too many moving parts (: redhat-rpm-config was just built, in about 10~15 minutes it'll be in the buildroot and should start making the dist-tag resolve correctly. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 16:34:32 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 12:34:32 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179504195.4735.1003.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705181046.23065.jkeating@redhat.com> <1179504195.4735.1003.camel@mccallum.corsepiu.local> Message-ID: <200705181234.32520.jkeating@redhat.com> On Friday 18 May 2007 12:03:15 Ralf Corsepius wrote: > Web author's lesson #1: Any web page which chokes if being invoked with > incorrect arguments is broken. That page isn't linked to by anything. You'd have to manually type that url in to get that error. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 18 16:43:42 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 18 May 2007 18:43:42 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <200705181131.25267.jkeating@redhat.com> References: <20070518160048.26b06d58@python3.es.egwn.lan> <20070518170710.7e962dbc.bugs.michael@gmx.net> <20070518172356.0dbe5007@python3.es.egwn.lan> <200705181131.25267.jkeating@redhat.com> Message-ID: <20070518184342.6506cd9e@python3.es.egwn.lan> Jesse Keating wrote : > On Friday 18 May 2007 11:23:56 Matthias Saou wrote: > > I thought it was the other way around... with ExcludeArch not being > > present in the source rpm, thus making it impossible for the compose > > tool to know that the resulting noarch package was only meant to be > > made available for some archs and not others, and OTOH having > > ExclusiveArch be passed into the source rpm and used by the compose > > tool. > > The compose tool we used internally for Core, and the new tool (mash) we're > using for the merged Fedora handle looking at _both_ ExcludeArch and > ExclusiveArch settings in the source rpm used to create the noarch package in > question. I don't believe Koji handles the ExclusiveArch case though, only > the ExcludeArch. (See firstboot for an example) Interesting, thanks. I just seem to have hit another bug in Koji, though : $ make build Created task: 10488 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=10488 Watching tasks (this may be safely interrupted)... 10488 build (dist-f8, devel:iwlwifi-firmware-2_14_3-1): free 10488 build (dist-f8, devel:iwlwifi-firmware-2_14_3-1): free -> open (ppc3.fedora.redhat.com) 10493 buildSRPMFromCVS (devel:iwlwifi-firmware-2_14_3-1): free 10493 buildSRPMFromCVS (devel:iwlwifi-firmware-2_14_3-1): free -> open (ppc3.fedora.redhat.com) 10493 buildSRPMFromCVS (devel:iwlwifi-firmware-2_14_3-1): open (ppc3.fedora.redhat.com) -> closed 0 free 1 open 1 done 0 failed 10495 buildArch (iwlwifi-firmware-2.14.3-1.src.rpm, noarch): open (ppc2.fedora.redhat.com) 10495 buildArch (iwlwifi-firmware-2.14.3-1.src.rpm, noarch): open (ppc2.fedora.redhat.com) -> closed 0 free 1 open 2 done 0 failed 10488 build (dist-f8, devel:iwlwifi-firmware-2_14_3-1): open (ppc3.fedora.redhat.com) -> FAILED: GenericError: Error importing RPM file. /mnt/koji/packages/iwlwifi-firmware/2.14.3/1/src/iwlwifi-firmware-2.14.3-1.src.rpm already exists. 0 free 0 open 2 done 1 failed make: *** [koji] Error 1 (sorry for the br0ked lines...) I've always been forcing the same tag for minor spec file changes following failed builds. It seems that Koji might not like that because of leftovers from previous failures... I'll try bumping the release, and will know immediately if that's the problem. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.61 0.48 0.42 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri May 18 16:47:43 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 18 May 2007 18:47:43 +0200 Subject: File conflicts in Fedora Extras devel - 20070109 In-Reply-To: <464D9CCD.6070108@hhs.nl> References: <20070109210622.8b03dc7f.bugs.michael@gmx.net> <20070517221455.36bb2ac4.bugs.michael@gmx.net> <20070518113936.GD21325@ryvius.pekin.waw.pl> <1179489591.4735.929.camel@mccallum.corsepiu.local> <464D9CCD.6070108@hhs.nl> Message-ID: <20070518184743.7e40e5fb@python3.es.egwn.lan> Hans de Goede wrote : > Ralf Corsepius wrote: > > On Fri, 2007-05-18 at 13:39 +0200, Dominik 'Rathann' Mierzejewski wrote: > >> On Thursday, 17 May 2007 at 22:14, Michael Schwendt wrote: > >>> On Tue, 9 Jan 2007 21:06:22 +0100, Michael Schwendt wrote: > >>> > >>>> This is just a reminder. > >>>> > >>>> These are all non-explicit package conflicts found in FE development. > >>>> I've filed several tickets plus a few more for FE<=6 (check out the > >>>> FE7Target bug) long ago. > > > >>> plib-devel - 1.8.4-8.fc6.i386 > >>> File conflict with: plib16-devel - 1.6.0-6.fc6.i386 > >>> /usr/include/plib/fnt.h > >>> /usr/include/plib/js.h > >>> /usr/include/plib/netBuffer.h > >>> /usr/include/plib/netChannel.h > >>> /usr/include/plib/netMessage.h > >>> /usr/include/plib/netMonitor.h > >>> /usr/include/plib/netSocket.h > >>> /usr/include/plib/pu.h > >>> /usr/include/plib/sg.h > >>> /usr/include/plib/sl.h > >>> /usr/include/plib/slPortability.h > >>> /usr/include/plib/sm.h > >>> /usr/include/plib/ssg.h > >>> /usr/include/plib/ssgAux.h > >>> /usr/include/plib/ssgKeyFlier.h > >>> /usr/include/plib/ssgaWaveSystem.h > >>> /usr/include/plib/ssgconf.h > >>> /usr/include/plib/ul.h > >>> /usr/include/plib/ulRTTI.h > >>> > >>> plib16-devel - 1.6.0-6.fc6.i386 > >>> File conflict with: plib-devel - 1.8.4-8.fc6.i386 > >>> /usr/include/plib/fnt.h > >>> /usr/include/plib/js.h > >>> /usr/include/plib/netBuffer.h > >>> /usr/include/plib/netChannel.h > >>> /usr/include/plib/netMessage.h > >>> /usr/include/plib/netMonitor.h > >>> /usr/include/plib/netSocket.h > >>> /usr/include/plib/pu.h > >>> /usr/include/plib/sg.h > >>> /usr/include/plib/sl.h > >>> /usr/include/plib/slPortability.h > >>> /usr/include/plib/sm.h > >>> /usr/include/plib/ssg.h > >>> /usr/include/plib/ssgAux.h > >>> /usr/include/plib/ssgKeyFlier.h > >>> /usr/include/plib/ssgaWaveSystem.h > >>> /usr/include/plib/ssgconf.h > >>> /usr/include/plib/ul.h > >>> /usr/include/plib/ulRTTI.h > >> plib16-devel should probably have an explicit conflict with plib-devel. > > A better approach would be to let one of the packages should install its > > headers into a different directory. > > > > Last time I talked about this with Matthias (the plib16 maintainer, I'm the > plib maintainer), we came to the conclusion that there are no packages > BuildRequiring plib16, and that it could be orphaned, so I guess that that is > the real solution. > > Matthias? Yup. I sort of forgot about it... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.23 0.35 0.37 From jkeating at redhat.com Fri May 18 16:47:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 12:47:49 -0400 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <20070518184342.6506cd9e@python3.es.egwn.lan> References: <20070518160048.26b06d58@python3.es.egwn.lan> <200705181131.25267.jkeating@redhat.com> <20070518184342.6506cd9e@python3.es.egwn.lan> Message-ID: <200705181247.49722.jkeating@redhat.com> On Friday 18 May 2007 12:43:42 Matthias Saou wrote: > I've always been forcing the same tag for minor spec file changes > following failed builds. It seems that Koji might not like that because > of leftovers from previous failures... I'll try bumping the release, > and will know immediately if that's the problem. Yes, you can't do that in Koji. Every build is unique, failed or complete. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 17:03:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 13:03:15 -0400 Subject: buildsys-macros package needs to be rebuilt In-Reply-To: <200705181229.19053.jkeating@redhat.com> References: <200705181214.42065.jkeating@redhat.com> <200705181229.19053.jkeating@redhat.com> Message-ID: <200705181303.15886.jkeating@redhat.com> On Friday 18 May 2007 12:29:18 Jesse Keating wrote: > On Friday 18 May 2007 12:14:41 Jesse Keating wrote: > > To apply the .fc8 dist tag. Working on it now, some builds will fail, > > sorry about this. > > Rather redhat-rpm-config. Ok, any builds that started about 10 minutes ago on should get the right dist values. Waiting for a build to prove my theory.... (; -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Fedora at FamilleCollet.com Fri May 18 17:15:25 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 18 May 2007 19:15:25 +0200 Subject: buildsys-macros package needs to be rebuilt In-Reply-To: <200705181303.15886.jkeating@redhat.com> References: <200705181214.42065.jkeating@redhat.com> <200705181229.19053.jkeating@redhat.com> <200705181303.15886.jkeating@redhat.com> Message-ID: <464DDF2D.8000303@FamilleCollet.com> Jesse Keating a ?crit : > > Ok, any builds that started about 10 minutes ago on should get the right dist > values. Waiting for a build to prove my theory.... (; Good theory ! Already 2 successful build for me with Build Target: dist-f8 Thanks a lot. Remi From j.w.r.degoede at hhs.nl Fri May 18 17:40:14 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 May 2007 19:40:14 +0200 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <200705181247.49722.jkeating@redhat.com> References: <20070518160048.26b06d58@python3.es.egwn.lan> <200705181131.25267.jkeating@redhat.com> <20070518184342.6506cd9e@python3.es.egwn.lan> <200705181247.49722.jkeating@redhat.com> Message-ID: <464DE4FE.1070003@hhs.nl> Jesse Keating wrote: > On Friday 18 May 2007 12:43:42 Matthias Saou wrote: >> I've always been forcing the same tag for minor spec file changes >> following failed builds. It seems that Koji might not like that because >> of leftovers from previous failures... I'll try bumping the release, >> and will know immediately if that's the problem. > > Yes, you can't do that in Koji. Every build is unique, failed or complete. > Well, I did do that with some pre freeze post merge fixes and it worked fine, are you sure Koji can't handle this, here is what Matthias is describing: make build fix, do not change N-V-R make tag copy and paste cvs tag line (failed because tag already existed), add -F to force tag make build This used to work under plague and seems to work fine for me under koji too. Regards, Hans From Fedora at FamilleCollet.com Fri May 18 17:26:10 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Fri, 18 May 2007 19:26:10 +0200 Subject: About common/Makefile.common Message-ID: <464DE1B2.1060402@FamilleCollet.com> Reading this file, i've just noticed : ifeq ($(BRANCH),devel) build: koji else build: plague endif This probably need a fix to use koji in devel and F-7. Remi. From jkeating at redhat.com Fri May 18 17:31:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 13:31:44 -0400 Subject: Koji doesn't like "ExclusiveArch: noarch i386 x86_64" noarch packages In-Reply-To: <464DE4FE.1070003@hhs.nl> References: <20070518160048.26b06d58@python3.es.egwn.lan> <200705181247.49722.jkeating@redhat.com> <464DE4FE.1070003@hhs.nl> Message-ID: <200705181331.45259.jkeating@redhat.com> On Friday 18 May 2007 13:40:14 Hans de Goede wrote: > Well, I did do that with some pre freeze post merge fixes and it worked > fine, are you sure Koji can't handle this, here is what Matthias is > describing: > > make build > > fix, do not change N-V-R > make tag > copy and paste cvs tag line (failed because tag already existed), add -F to > force tag > make build > > This used to work under plague and seems to work fine for me under koji > too. I think it depends on at what point the failure occurs. If some of the packages have been imported you'll lose as those n-v-rs are already in the db and the db has to be unique. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 17:33:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 13:33:14 -0400 Subject: About common/Makefile.common In-Reply-To: <464DE1B2.1060402@FamilleCollet.com> References: <464DE1B2.1060402@FamilleCollet.com> Message-ID: <200705181333.14809.jkeating@redhat.com> On Friday 18 May 2007 13:26:10 Remi Collet wrote: > Reading this file, i've just noticed : > > ifeq ($(BRANCH),devel) > build: koji > else > build: plague > endif > > This probably need a fix to use koji in devel and F-7. > Are you not updated? I see ifneq (, $(filter devel F-7, $(BRANCH))) build: koji else build: plague endif -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Fri May 18 17:34:58 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 18 May 2007 13:34:58 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179498623.4735.991.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> <1179498037.3807.6.camel@localhost.localdomain> <1179498623.4735.991.camel@mccallum.corsepiu.local> Message-ID: <464DE3C2.9050608@redhat.com> Ralf Corsepius wrote: > Did you ever consider that there might be users who work over low > bandwidth lines and/or don't want to wait for hours until the buildsys > returns? As an engineer who does this all the time on crappy wifi connections from neighbors' for a large build that does take 4 hours for a build to complete from unpack to debuginfo complete on all arches (though I'm including s390, ia64, etc), I'd rather have it wait. It's not that much traffic and it's a heck of a lot better than having to wait for all my massive amounts of email to download before I know whether or not my build failed because of a patch not applying or something silly. For me, and for some others that aren't necessarily at Red Hat, this means I don't need to VPN in, which is important over crappy connections. From nicolas.mailhot at laposte.net Fri May 18 17:40:29 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 18 May 2007 19:40:29 +0200 Subject: buildsys-macros package needs to be rebuilt In-Reply-To: <464DDF2D.8000303@FamilleCollet.com> References: <200705181214.42065.jkeating@redhat.com> <200705181229.19053.jkeating@redhat.com> <200705181303.15886.jkeating@redhat.com> <464DDF2D.8000303@FamilleCollet.com> Message-ID: <1179510029.16633.6.camel@rousalka.dyndns.org> Le vendredi 18 mai 2007 ? 19:15 +0200, Remi Collet a ?crit : > Jesse Keating a ?crit : > > > > Ok, any builds that started about 10 minutes ago on should get the right dist > > values. Waiting for a build to prove my theory.... (; > > Good theory ! > > Already 2 successful build for me with Build Target: dist-f8 It's not fixed for people that want to do rawhide mock builds. (am I the only one who does local mock builds before pushing stuff on koji?) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Fri May 18 17:40:58 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 18 May 2007 20:40:58 +0300 Subject: certificate check bug in Makefile.common Message-ID: <200705182040.58551.ville.skytta@iki.fi> There appears to be a bug in the certificate check in Makefile.common: $ make new-sources FILES=lirc-0.8.2pre2.tar.bz2 /bin/sh: line 0: [: lirc-0.8.2pre2.tar.bz2: integer expression expected [...] The attached patch should fix it. Also, I wonder if it'd be better to check $HOME/.koji/client.crt instead of ~/.fedora.cert? -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile-certcheck.patch Type: text/x-diff Size: 924 bytes Desc: not available URL: From jkeating at redhat.com Fri May 18 17:44:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 13:44:35 -0400 Subject: buildsys-macros package needs to be rebuilt In-Reply-To: <1179510029.16633.6.camel@rousalka.dyndns.org> References: <200705181214.42065.jkeating@redhat.com> <464DDF2D.8000303@FamilleCollet.com> <1179510029.16633.6.camel@rousalka.dyndns.org> Message-ID: <200705181344.35739.jkeating@redhat.com> On Friday 18 May 2007 13:40:29 Nicolas Mailhot wrote: > It's not fixed for people that want to do rawhide mock builds. (am I the > only one who does local mock builds before pushing stuff on koji?) Oh, for that you need to get http://koji.fedoraproject.org/packages/redhat-rpm-config/8.0.45/16.fc8/noarch/redhat-rpm-config-8.0.45-16.fc8.noarch.rpm in a repo your mock can pull from. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri May 18 17:50:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 18 May 2007 19:50:27 +0200 Subject: buildsys-macros package needs to be rebuilt In-Reply-To: <200705181344.35739.jkeating@redhat.com> References: <200705181214.42065.jkeating@redhat.com> <464DDF2D.8000303@FamilleCollet.com> <1179510029.16633.6.camel@rousalka.dyndns.org> <200705181344.35739.jkeating@redhat.com> Message-ID: <1179510627.12513.3.camel@rousalka.dyndns.org> Le vendredi 18 mai 2007 ? 13:44 -0400, Jesse Keating a ?crit : > On Friday 18 May 2007 13:40:29 Nicolas Mailhot wrote: > > It's not fixed for people that want to do rawhide mock builds. (am I the > > only one who does local mock builds before pushing stuff on koji?) > > Oh, for that you need to get > http://koji.fedoraproject.org/packages/redhat-rpm-config/8.0.45/16.fc8/noarch/redhat-rpm-config-8.0.45-16.fc8.noarch.rpm > in a repo your mock can pull from. Two points: 1. shouldn't this be dumped in the current default rawhide repos mock looks at for macros? (so change is transparent for users?) 2. I really hate the fact dist has been merged in redhat-rpm-config. The old system had the nice property one could just fork buildsys-macros to have different repotags for local not-clean builds. redhat-rpm-config brings in a lot of stuff I really don't want to touch or fork -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Fri May 18 17:59:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 13:59:49 -0400 Subject: buildsys-macros package needs to be rebuilt In-Reply-To: <1179510627.12513.3.camel@rousalka.dyndns.org> References: <200705181214.42065.jkeating@redhat.com> <200705181344.35739.jkeating@redhat.com> <1179510627.12513.3.camel@rousalka.dyndns.org> Message-ID: <200705181359.49763.jkeating@redhat.com> On Friday 18 May 2007 13:50:27 Nicolas Mailhot wrote: > Two points: > > 1. shouldn't this be dumped in the current default rawhide repos mock > looks at for macros? (so change is transparent for users?) Well, "rawhide" is still all Fedora 7 stuff. The dist-f8 is pre-rawhide content. Not entirely sure how to express that in Mock. As to your other point, that is somewhat valid. We approved making the macros available on the user's system instead of just hidden away in the buildsystem somewhere, and the logical place to toss them was redhat-rpm-config with the rest of said settings. Perhaps if there is compelling enough reason we could split it out again... but I'd rather not. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Fri May 18 18:04:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 18 May 2007 14:04:45 -0400 Subject: certificate check bug in Makefile.common In-Reply-To: <200705182040.58551.ville.skytta@iki.fi> References: <200705182040.58551.ville.skytta@iki.fi> Message-ID: <1179511485.24886.17.camel@aglarond.local> On Fri, 2007-05-18 at 20:40 +0300, Ville Skytt? wrote: > There appears to be a bug in the certificate check in Makefile.common: [snip] > The attached patch should fix it. Thanks, applied > Also, I wonder if it'd be better to check > $HOME/.koji/client.crt instead of ~/.fedora.cert? The reason we don't is that we use ~/.fedora.cert as the cert with curl when doing uploads. Ultimately, we should get to having one place for this... Jeremy From ville.skytta at iki.fi Fri May 18 18:08:20 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 18 May 2007 21:08:20 +0300 Subject: No build notification mails from koji (was: Re: Broken upgrade paths in F7) In-Reply-To: <20070518141343.GA22296@ryvius.pekin.waw.pl> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> Message-ID: <200705182108.20386.ville.skytta@iki.fi> On Friday 18 May 2007, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 18 May 2007 at 15:48, Jesse Keating wrote: > > > > Hrm, Koji emails the owner of the package being built by default. It > > goes to @fedoraproject.org. Are you not getting mail sent to > > the address you have configured in your Fedora Account ? > > Now that you mentioned it, I'm not getting those either. Ditto, nor do I remember ever receiving those. Earlier it at least tried (see https://bugzilla.redhat.com/239182) but now my 5 most recent builds do not have a buildNotification task, there's only buildSRPMFromCVS, a bunch of buildArch's, and finally a tagBuild (eg. http://koji.fedoraproject.org/koji/taskinfo?taskID=10591). scop at fp.org works. From jkeating at redhat.com Fri May 18 18:10:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 14:10:49 -0400 Subject: Fedora Build Status Message-ID: <200705181410.50005.jkeating@redhat.com> We've forked F-7 away from the devel/ branch in CVS. This means a couple things: Builds from F-7/ are now directed to a new tag, 'dist-fc7-updates-candidate'. This is the holding tag for potential and "-testing" updates for Fedora 7. Builds will sit here until we bring bodhi online and start taking pre-requests for Fedora 7 updates. An important thing to note with this tag, builds done here do _not_ automatically update the buildroot. This is a major point of contention with lots of heated feelings on both sides of the plate. On one side, a -testing update or candidate update has the potential to be used by other updates that eventually get shipped, but if said candidate or -test update has to be pulled, doom. On the other side, building a set of interdependent packages requires interaction with release engineering to tag packages correctly to make them available in the buildroot. Some of the same problems apply but the window is smaller and more controlled. We could open the tag and allow any maintainer to apply the 'dist-fc7-updates' tag themselves to a build, as this would allow it to show up in the buildroot. Still an interactive process and not automated in any way. I think this whole scenario should be open for discussion and I'm welcoming ideas. Builds from devel/ are tagged with 'dist-f8'. This tag inherits from dist-fc7-updates, which inherits from dist-fc7. Right now dist-f8 gets all of Fedora 7 (and updates) for free, so the only things that really need to be built are changes from Fedora 7. Once Fedora 7 has gone "GOLD" we will switch rawhide to compose from 'dist-f8'. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri May 18 18:13:10 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Fri, 18 May 2007 21:13:10 +0300 Subject: No build notification mails from koji (was: Re: Broken upgrade paths in F7) In-Reply-To: <200705182108.20386.ville.skytta@iki.fi> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <20070518141343.GA22296@ryvius.pekin.waw.pl> <200705182108.20386.ville.skytta@iki.fi> Message-ID: <200705182113.10896.ville.skytta@iki.fi> On Friday 18 May 2007, you wrote: > On Friday 18 May 2007, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 18 May 2007 at 15:48, Jesse Keating wrote: > > > Hrm, Koji emails the owner of the package being built by default. It > > > goes to @fedoraproject.org. Are you not getting mail sent to > > > the address you have configured in your Fedora Account ? > > > > Now that you mentioned it, I'm not getting those either. > > Ditto, nor do I remember ever receiving those. Earlier it at least tried > (see https://bugzilla.redhat.com/239182) but now my 5 most recent builds do > not have a buildNotification task, there's only buildSRPMFromCVS, a bunch > of buildArch's, and finally a tagBuild (eg. > http://koji.fedoraproject.org/koji/taskinfo?taskID=10591). scop at fp.org > works. Eh, and of course while I wrote the above, two build notifications arrived properly in my inbox. Still no trace of any buildNotification tasks in the koji web UI though, even for those two mails that I got. From jkeating at redhat.com Fri May 18 18:16:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 14:16:12 -0400 Subject: No build notification mails from koji (was: Re: Broken upgrade paths in F7) In-Reply-To: <200705182113.10896.ville.skytta@iki.fi> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705182108.20386.ville.skytta@iki.fi> <200705182113.10896.ville.skytta@iki.fi> Message-ID: <200705181416.13024.jkeating@redhat.com> On Friday 18 May 2007 14:13:10 Ville Skytt? wrote: > Eh, and of course while I wrote the above, two build notifications arrived > properly in my inbox. ?Still no trace of any buildNotification tasks in the > koji web UI though, even for those two mails that I got. buildNotifications are a separate top level task apparently and aren't viewable in the build task list. http://koji.fedoraproject.org/koji/tasks?method=buildNotification&state=all&order=-completion_time shows the tasks. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri May 18 18:19:57 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 May 2007 14:19:57 -0400 Subject: Branching done ?? In-Reply-To: <464DC6DD.8080402@hhs.nl> References: <464DC421.2020903@hhs.nl> <1179500939.3046.9.camel@vader.jdub.homelinux.org> <464DC6DD.8080402@hhs.nl> Message-ID: <20070518181957.GB19544@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > However a new package for which the dirs have been created last night (iow > shortly before the branch) doesn't have an F-7, the involved package is > "ants", the same probably goes for "rott" (which I still have to import) as > rott was created at the same time. The branch was done for every package that had shipped in rawhide. I suspect things added in the interim from the last push are left out. Bill From notting at redhat.com Fri May 18 18:21:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 May 2007 14:21:25 -0400 Subject: Branching done ?? In-Reply-To: <20070518181957.GB19544@nostromo.devel.redhat.com> References: <464DC421.2020903@hhs.nl> <1179500939.3046.9.camel@vader.jdub.homelinux.org> <464DC6DD.8080402@hhs.nl> <20070518181957.GB19544@nostromo.devel.redhat.com> Message-ID: <20070518182125.GC19544@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > However a new package for which the dirs have been created last night (iow > > shortly before the branch) doesn't have an F-7, the involved package is > > "ants", the same probably goes for "rott" (which I still have to import) as > > rott was created at the same time. > > The branch was done for every package that had shipped in rawhide. I > suspect things added in the interim from the last push are left out. ... and I'll get to this in the next couple of hours. Bill From jwboyer at jdub.homelinux.org Fri May 18 19:41:02 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 18 May 2007 14:41:02 -0500 Subject: 5/18/2007 Broken upgrade paths report Message-ID: <1179517262.3046.19.camel@vader.jdub.homelinux.org> The number of packages with broken upgrade paths keeps dropping. Great work maintainers! josh asymptote: FE6 > F7 (0:1.28-1.fc6 > 0:1.26-1.fc7) asymptote-1.28-1.fc7 dist-fc7 jpo em8300-kmod: FE6 > F7 (0:0.16.2-1.2.6.20_1.2948.fc6 > 0:0.16.2-0.2.6.20_1.3104.fc7.1.rc2) em8300-kmod-0.16.2-5.2.6.21_1.3149.fc7 dist-fc7 scop fortune-firefly: FE6 > F7 (0:2.1.2-2.fc6 > 0:2.1.1-2.fc6) fuse: FE6 > F7 (0:2.6.5-1.fc6 > 0:2.6.3-2.fc7) fuse-2.6.5-1.fc7 dist-fc7 peter gallery2: FE6 > F7 (0:2.2-0.5.svn20070506.fc6 > 0:2.1-0.24.svn20060817.fc6) gallery2-2.2-0.5.svn20070506.fc7 dist-fc7 jwb gtk+extra: FE6 > F7 (0:2.1.1-4.fc6 > 0:2.1.1-3.fc6) gtk+extra-2.1.1-4.fc7 dist-fc7 dionysos librfid: FE6 > F7 (0:0.1.0-3.1996svn.fc6 > 0:0.1.0-2.fc7) librfid-0.1.0-3.1996svn.fc7 dist-fc7 kushal linphone: FE6 > F7 (0:1.7.1-2.fc6 > 0:1.7.1-1.fc7) linphone-1.7.1-2.fc7 dist-fc7 jcollie m4: FC6-updates > F7 (0:1.4.8-2 > 0:1.4.8-1) m4-1.4.8-2.fc7 dist-fc7 jkeating monotone: FE6 > F7 (0:0.35-2.fc6 > 0:0.34-1.fc7) monotone-0.35-3.fc7 dist-fc7 roland perl-Module-ScanDeps: FE6 > F7 (0:0.74-1.fc6 > 0:0.73-1.fc7) perl-Module-ScanDeps-0.74-1.fc7 dist-fc7 jpo perl-Pod-Strip: FE6 > F7 (0:1.02-2.fc6 > 0:1.02-1.fc7) perl-Pod-Strip-1.02-2.fc7 dist-fc7 jpo perl-Test-Warn: FE6 > F7 (0:0.10-1.fc6 > 0:0.09-1.fc7) perl-Test-Warn-0.10-1.fc7 dist-fc7 jpo quodlibet: FE6 > F7 (0:1.0-1.fc6 > 0:0.24-7.fc7) quodlibet-1.0-1.fc7 dist-fc7 jcollie rosegarden4: FE6 > F7 (0:1.5.1-1.fc6 > 0:1.4.0-1.fc7) rrdtool: FE6 > F7 (0:1.2.23-3.fc6 > 0:1.2.19-2.fc7) rrdtool-1.2.23-3.fc7 dist-fc7 jwilson shorewall: FE6 > F7 (0:3.4.3-1.fc6 > 0:3.4.2-1.fc7) shorewall-3.4.3-1.fc7 dist-fc7 robmv smb4k: FE6 > F7 (0:0.8.3-1.fc6 > 0:0.8.2-1.fc7) smb4k-0.8.3-1.fc7 dist-fc7 mgarski TeXmacs: FE6 > F7 (0:1.0.6.10-2.fc6 > 0:1.0.6.9-1.fc7) TeXmacs-1.0.6.10-2.fc7 dist-fc7 gemi transmission: FE6 > F7 (0:0.72-1.fc6 > 0:0.71-1.fc7) transmission-0.72-1.fc7 dist-fc7 denis viewvc: FE6 > F7 (0:1.0.4-1.fc6 > 0:1.0.3-13.fc7) viewvc-1.0.4-1.fc7 dist-fc7 bojan wavpack: FE6 > F7 (0:4.41-1.fc6 > 0:4.40-1.1.fc7) wavpack-4.41-1.fc7 dist-fc7 peter From jkeating at redhat.com Fri May 18 20:14:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 May 2007 16:14:52 -0400 Subject: Koji outage Message-ID: <200705181614.52889.jkeating@redhat.com> We seem to be experiencing some technical difficulties. Admins are investigating, please stand by while we herd the hamsters back to their wheels. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Fri May 18 20:27:08 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 18 May 2007 16:27:08 -0400 Subject: Fedora Bugzilla Merge Plan Message-ID: <464E0C1C.2030700@redhat.com> What Will Happen? ================= "Fedora Core" and "Fedora Extras" Bugzilla products will merge into a single product named "Fedora". All Versions and components of the previous two products will exist in the new combined product, then all bugs will be migrated. dkl will make this change without any mail being sent. I hope that we can aim for Monday, May 21st EDT night to make this change. Other Things Needing to be Fixed? ================================= 1) Canned Queries of Bugzilla in various scripts and URL's 2) Package Review submission template 3) owners.list and owners-sync script Anything else people can think of that needs fixing to cope with this Bugzilla change? Warren Togami wtogami at redhat.com From tcallawa at redhat.com Fri May 18 20:31:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 18 May 2007 15:31:10 -0500 Subject: Fedora Bugzilla Merge Plan In-Reply-To: <464E0C1C.2030700@redhat.com> References: <464E0C1C.2030700@redhat.com> Message-ID: <1179520270.6254.192.camel@localhost.localdomain> On Fri, 2007-05-18 at 16:27 -0400, Warren Togami wrote: > What Will Happen? > ================= > "Fedora Core" and "Fedora Extras" Bugzilla products will merge into a > single product named "Fedora". All Versions and components of the > previous two products will exist in the new combined product, then all > bugs will be migrated. > > dkl will make this change without any mail being sent. I hope that we > can aim for Monday, May 21st EDT night to make this change. > > Other Things Needing to be Fixed? > ================================= > 1) Canned Queries of Bugzilla in various scripts and URL's > 2) Package Review submission template > 3) owners.list and owners-sync script > > Anything else people can think of that needs fixing to cope with this > Bugzilla change? FE-Legal needs to be renamed to something else. Probably. ~spot From wtogami at redhat.com Fri May 18 20:37:56 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 18 May 2007 16:37:56 -0400 Subject: Fedora Bugzilla Merge Plan In-Reply-To: <1179520270.6254.192.camel@localhost.localdomain> References: <464E0C1C.2030700@redhat.com> <1179520270.6254.192.camel@localhost.localdomain> Message-ID: <464E0EA4.5080104@redhat.com> Tom "spot" Callaway wrote: > > FE-Legal needs to be renamed to something else. Probably. > Renaming of tracker bugs can be done independently of this. Warren From wcohen at redhat.com Fri May 18 21:02:18 2007 From: wcohen at redhat.com (William Cohen) Date: Fri, 18 May 2007 17:02:18 -0400 Subject: problem with the fedora cvs Message-ID: <464E145A.1090109@redhat.com> Hi all, I am trying to set things up so I can make any needed changes in oprofile package I maintain. I attempted to follow the instructions on http://fedoraproject.org/wiki/PackageMaintainers/CvsAccess I am able to check out the oprofile package as expected, but I attempted to bump the version number and check in the modified oprofile/devel/oprofile.spec file, I get the following message: $ cvs ci oprofile.spec **** Access allowed: wcohen is in ACL for rpms/oprofile/devel. Checking in oprofile.spec; /cvs/pkgs/rpms/oprofile/devel/oprofile.spec,v <-- oprofile.spec new revision: 1.53; previous revision: 1.52 cvs [commit aborted]: could not open lock file `/cvs/pkgs/rpms/oprofile/devel/,oprofile.spec,': Permission denied cvs commit: saving log message in /tmp/cvs8l98Nw I checked and I appear to be the maintainer of the package. What do I need to correct, so that I am able to check in changes? -Will From roland at redhat.com Fri May 18 21:09:06 2007 From: roland at redhat.com (Roland McGrath) Date: Fri, 18 May 2007 14:09:06 -0700 (PDT) Subject: problem with the fedora cvs In-Reply-To: William Cohen's message of Friday, 18 May 2007 17:02:18 -0400 <464E145A.1090109@redhat.com> Message-ID: <20070518210906.A6D001F804E@magilla.localdomain> > $ cvs ci oprofile.spec > **** Access allowed: wcohen is in ACL for rpms/oprofile/devel. > Checking in oprofile.spec; > /cvs/pkgs/rpms/oprofile/devel/oprofile.spec,v <-- oprofile.spec > new revision: 1.53; previous revision: 1.52 > cvs [commit aborted]: could not open lock file > `/cvs/pkgs/rpms/oprofile/devel/,oprofile.spec,': Permission denied > cvs commit: saving log message in /tmp/cvs8l98Nw It's not possible for this to be a problem on your end. Either the CVS repository directory's permissions or the accounts setup on the server must be out of whack. From rc040203 at freenet.de Sat May 19 03:35:06 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 19 May 2007 05:35:06 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705181234.32520.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705181046.23065.jkeating@redhat.com> <1179504195.4735.1003.camel@mccallum.corsepiu.local> <200705181234.32520.jkeating@redhat.com> Message-ID: <1179545706.4735.1042.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 12:34 -0400, Jesse Keating wrote: > On Friday 18 May 2007 12:03:15 Ralf Corsepius wrote: > > Web author's lesson #1: Any web page which chokes if being invoked with > > incorrect arguments is broken. > > That page isn't linked to by anything. Irrelevant and a weak excuse - It's bug. Any program that segfaults, triggers "divisions by zero" or a "stack-trace" is upon invalid input is broken. > You'd have to manually type that url in to get that error. Happens if you search koji.fedoraproject.org with a browser. Ralf From denis at poolshark.org Sat May 19 12:40:55 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 19 May 2007 14:40:55 +0200 Subject: 5/18/2007 Broken upgrade paths report In-Reply-To: <1179517262.3046.19.camel@vader.jdub.homelinux.org> References: <1179517262.3046.19.camel@vader.jdub.homelinux.org> Message-ID: <464EF057.60207@poolshark.org> Josh Boyer wrote: > transmission: > FE6 > F7 (0:0.72-1.fc6 > 0:0.71-1.fc7) > transmission-0.72-1.fc7 dist-fc7 denis I sent a tag request to rel-eng a few days ago, not sure what's up. From denis at poolshark.org Sat May 19 12:54:11 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 19 May 2007 14:54:11 +0200 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <1179415883.6254.74.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> Message-ID: <464EF373.7010203@poolshark.org> Tom "spot" Callaway wrote: > All we're asking (well, maybe all _I_ am asking) is that when people > feel like they need to break one of the guidelines, they present their > case and document that case in the spec file. On that topic, how does one write comments in a spec file ? I remember a few years ago I was asked to remove all '# comments' lines from scriptlets apparently because they "could cause problems"... -denis From wwoods at redhat.com Sat May 19 13:10:15 2007 From: wwoods at redhat.com (Will Woods) Date: Sat, 19 May 2007 09:10:15 -0400 Subject: 5/18/2007 Broken upgrade paths report In-Reply-To: <464EF057.60207@poolshark.org> References: <1179517262.3046.19.camel@vader.jdub.homelinux.org> <464EF057.60207@poolshark.org> Message-ID: <1179580215.7288.67.camel@zebes.localdomain> On Sat, 2007-05-19 at 14:40 +0200, Denis Leroy wrote: > Josh Boyer wrote: > > transmission: > > FE6 > F7 (0:0.72-1.fc6 > 0:0.71-1.fc7) > > transmission-0.72-1.fc7 dist-fc7 denis > > I sent a tag request to rel-eng a few days ago, not sure what's up. Jesse asked if you had tested the new build at all; we never heard back (at least, not on the list). So - has the new build been tested? what's different in 0.71? Is it just a bugfix release? As long as you're pretty sure that the changes are safe to pull in, we'll tag it. If you could be sure to respond to rel-eng about this, we'll get it tagged ASAP. -w -------------- 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 May 19 13:21:19 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 19 May 2007 15:21:19 +0200 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <464EF373.7010203@poolshark.org> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> Message-ID: <20070519152119.adaf252b.bugs.michael@gmx.net> On Sat, 19 May 2007 14:54:11 +0200, Denis Leroy wrote: > Tom "spot" Callaway wrote: > > All we're asking (well, maybe all _I_ am asking) is that when people > > feel like they need to break one of the guidelines, they present their > > case and document that case in the spec file. > > On that topic, how does one write comments in a spec file ? # Like this ## or this in many script languages. > I remember a > few years ago I was asked to remove all '# comments' lines from > scriptlets apparently because they "could cause problems"... No. You were only asked to not add such comment lines _after_ scriptlet sections in the spec file, because the comments would be included in the scriptlet bodies, even if a scriptlet section is passed to /sbin/ldconfig, which doesn't understand the contents and breaks badly. From denis at poolshark.org Sat May 19 13:45:34 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 19 May 2007 15:45:34 +0200 Subject: 5/18/2007 Broken upgrade paths report In-Reply-To: <1179580215.7288.67.camel@zebes.localdomain> References: <1179517262.3046.19.camel@vader.jdub.homelinux.org> <464EF057.60207@poolshark.org> <1179580215.7288.67.camel@zebes.localdomain> Message-ID: <464EFF7E.9080506@poolshark.org> Will Woods wrote: > On Sat, 2007-05-19 at 14:40 +0200, Denis Leroy wrote: >> Josh Boyer wrote: >>> transmission: >>> FE6 > F7 (0:0.72-1.fc6 > 0:0.71-1.fc7) >>> transmission-0.72-1.fc7 dist-fc7 denis >> I sent a tag request to rel-eng a few days ago, not sure what's up. > > Jesse asked if you had tested the new build at all; we never heard back > (at least, not on the list). I guess the reply only went to Jesse. Sorry. > So - has the new build been tested? what's different in 0.71? Is it > just a bugfix release? As long as you're pretty sure that the changes > are safe to pull in, we'll tag it. It is a bugfix release from 0.71, and I've tested the build on i386. I'm confident the changes are safe to pull in. thanks! -denis From denis at poolshark.org Sat May 19 13:50:40 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 19 May 2007 15:50:40 +0200 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <20070519152119.adaf252b.bugs.michael@gmx.net> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> Message-ID: <464F00B0.3060903@poolshark.org> Michael Schwendt wrote: > On Sat, 19 May 2007 14:54:11 +0200, Denis Leroy wrote: > >> Tom "spot" Callaway wrote: >>> All we're asking (well, maybe all _I_ am asking) is that when people >>> feel like they need to break one of the guidelines, they present their >>> case and document that case in the spec file. >> On that topic, how does one write comments in a spec file ? > > # Like this > ## or this in many script languages. > >> I remember a >> few years ago I was asked to remove all '# comments' lines from >> scriptlets apparently because they "could cause problems"... > > No. You were only asked to not add such comment lines _after_ scriptlet > sections in the spec file, because the comments would be included in the > scriptlet bodies, even if a scriptlet section is passed to /sbin/ldconfig, > which doesn't understand the contents and breaks badly. Ok, so %install # comment make something is not good. But # comment %install make something is good ? From denis at poolshark.org Sat May 19 14:11:15 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 19 May 2007 16:11:15 +0200 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <464F00B0.3060903@poolshark.org> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> Message-ID: <464F0583.4030009@poolshark.org> Denis Leroy wrote: > Michael Schwendt wrote: >> On Sat, 19 May 2007 14:54:11 +0200, Denis Leroy wrote: >> >>> Tom "spot" Callaway wrote: >>>> All we're asking (well, maybe all _I_ am asking) is that when people >>>> feel like they need to break one of the guidelines, they present their >>>> case and document that case in the spec file. >>> On that topic, how does one write comments in a spec file ? >> >> # Like this >> ## or this in many script languages. >> >>> I remember a few years ago I was asked to remove all '# comments' >>> lines from scriptlets apparently because they "could cause problems"... >> >> No. You were only asked to not add such comment lines _after_ scriptlet >> sections in the spec file, because the comments would be included in the >> scriptlet bodies, even if a scriptlet section is passed to >> /sbin/ldconfig, >> which doesn't understand the contents and breaks badly. Not enough coffee. You meant "after scriptlet sections ON THE SAME LINE" as in %post -p /sbin/ldconfig # bad comment From pmatilai at laiskiainen.org Sat May 19 14:13:29 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 19 May 2007 17:13:29 +0300 (EEST) Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <464F0583.4030009@poolshark.org> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> Message-ID: On Sat, 19 May 2007, Denis Leroy wrote: > Denis Leroy wrote: >> Michael Schwendt wrote: >>> On Sat, 19 May 2007 14:54:11 +0200, Denis Leroy wrote: >>> >>>> Tom "spot" Callaway wrote: >>>>> All we're asking (well, maybe all _I_ am asking) is that when people >>>>> feel like they need to break one of the guidelines, they present their >>>>> case and document that case in the spec file. >>>> On that topic, how does one write comments in a spec file ? >>> >>> # Like this >>> ## or this in many script languages. >>> >>>> I remember a few years ago I was asked to remove all '# comments' lines >>>> from scriptlets apparently because they "could cause problems"... >>> >>> No. You were only asked to not add such comment lines _after_ scriptlet >>> sections in the spec file, because the comments would be included in the >>> scriptlet bodies, even if a scriptlet section is passed to /sbin/ldconfig, >>> which doesn't understand the contents and breaks badly. > > Not enough coffee. You meant "after scriptlet sections ON THE SAME LINE" as > in > > %post -p /sbin/ldconfig # bad comment That's bad, but this is also bad: No, that's fine. What is NOT fine is this: # post scriptlet %post -p /sbin/ldconfig # postun scriptlet %postun -p /sbin/ldconfig The "# postun scriptlet" comment would get included in scriptlet body which ldconfig tries to interpret and breaks. - Panu - From bugs.michael at gmx.net Sat May 19 14:32:44 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sat, 19 May 2007 16:32:44 +0200 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <464F0583.4030009@poolshark.org> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> Message-ID: <20070519163244.4cd70e5b.bugs.michael@gmx.net> On Sat, 19 May 2007 16:11:15 +0200, Denis Leroy wrote: > >> # Like this > >> ## or this in many script languages. > >> > >>> I remember a few years ago I was asked to remove all '# comments' > >>> lines from scriptlets apparently because they "could cause problems"... > >> > >> No. You were only asked to not add such comment lines _after_ scriptlet > >> sections in the spec file, because the comments would be included in the > >> scriptlet bodies, even if a scriptlet section is passed to > >> /sbin/ldconfig, > >> which doesn't understand the contents and breaks badly. > > Not enough coffee. You meant "after scriptlet sections ON THE SAME LINE" > as in > > %post -p /sbin/ldconfig # bad comment That one would not even rpmbuild. ;) Rule of thumb: Avoid comment lines after %post/postun/pre/preun (and likely also the trigger sections) up to the next non-scriptlet section. This is what I refer to: ... %post -p /sbin/ldconfig # These comment lines are included in the %post script. # *Everything* up to the following script section is included. # See: rpm --query --scripts ... %postun -p /sbin/ldconfig # And this comment is included in the %postun (!) script and # breaks ldconfig, too. %check ... Note that even if the script sections were executed with default /bin/sh, comments _before_ a %post/postun/... section would make it into the previous [and hence wrong] script body. From trond.danielsen at gmail.com Sun May 20 10:37:33 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Sun, 20 May 2007 12:37:33 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <20070518141343.GA22296@ryvius.pekin.waw.pl> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705180917.09573.jkeating@redhat.com> <1179495606.4735.960.camel@mccallum.corsepiu.local> <200705180948.26750.jkeating@redhat.com> <20070518141343.GA22296@ryvius.pekin.waw.pl> Message-ID: <409676c70705200337i61370d56wdea5ccb515f4fea9@mail.gmail.com> 2007/5/18, Dominik 'Rathann' Mierzejewski : > On Friday, 18 May 2007 at 15:48, Jesse Keating wrote: > > On Friday 18 May 2007 09:40:06 Ralf Corsepius wrote: > [...] > > > Also, IMO, --nowait should be made default. Not using it is really > > > nagging (I only knew about it, because somebody else already had > > > complained and you had mentioned it some time last week). > > > > The reason it isn't made default is that there is no converse of it, > > IE --wait. So by making it not default it gives users the opportunity to > > either use it if they like, or add a --nowait flag to disable it. One can't > > have it disabled by default and force a way to have it actually wait. > > Well, that's a regression compared to plague. Please fix it (or do I have > to file a bug against koji to have it done?). I agree with Ralf that koji > should mimic plague behaviour in that respect. I also agree. I think that an optional --wait flag make more sense. I usually do not want to sit around and wait for the build to finish, so I instantly press Ctrl-c to stop watching the build. > Now that you mentioned it, I'm not getting those either. In fact, I didn't > even know there *were* @fedoraproject.org accounts for all > contributors. Is it documented somewhere? http://fedoraproject.org/wiki/EmailAliases. It is hit #2 if you search for email on the wiki. -- Trond Danielsen From fedora at leemhuis.info Sun May 20 12:10:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 14:10:28 +0200 Subject: EPEL report week 20, 2007 Message-ID: <46503AB4.8020103@leemhuis.info> Hi all! Please find below this weeks EPEL report. It's also in the wiki at http://fedoraproject.org/wiki/EPEL/Reports/Week20 Cu thl ---- = Weekly EPEL Summary = Week 20/2007 == Most important happenings == * mether (RahulSundaram) did some proof reading and cleanups in various EPEL documents in the wiki; thx for your help mether! quaid (KarstenWade) is also working on cleaning up the wiki. * "start signal" for Fedora contributors was send; see https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00323.html ; EPEL got quite some new contributors and packages due to it * [https://www.redhat.com/archives/epel-devel-list/2007-May/msg00052.html some discussions] about the proper update strategy for packages == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) Stahnma (MichaelStahnke) just missed the meeting. Others that participated the meeting: Jeff_S, lmacken, smooge === Summary === * 00:02 -- repotags/interaction with 3rd party repos -- owner: all * we wait for more discussion on the list (in particular for Fernando Lopez-Lezcano before we decide how to move on) * knurd also want to discuss cooperation with CentOS/z00dax a bit, which might have impact to this, too * 00:04 -- vacant seat in the steering committee * knurd mailed those five people thimm proposed; four answered; they gave a "no" or a "only if you don't find somebody else" kind of answers; we wait another week and evaluate; maybe z00dax could join the Steering Committee (even without being a contributor for EPEL, as he can't sign the CLA) * 00:06 -- finish the wiki docs and remove the warnings * mether and quaid did some cleanups; quaid will do some more over the next few days; the plan is to remove the those "not official yet" warning by next weeks meeting, but the EPEL repo itself stays unannounced * some discussion about bodhi with lmacken under this topic; see full log for details * 00:14 -- Free discussion around EPEL * 00:15 nirik asked for comments regarding Xfce in EPEL, as Xfce will soon get into CentOS Extras, too; (see full log for details); knurd mentions that we should have it in EPEL, even if CentOS Extras has it, but we should try to find a way of cooperation so bugfixes find their way into CentOS Extras, EPEL and Fedora * 00:20 nirik> "oh, how about mock configs?" dgilmore will make sure they work * 00:25 smooge> "Will we be answering who the EPEL customers are thought to be to distinguish it from other customer bases?"; we continue on the list, but we maybe should write something up and put it in the wiki * 00:26 some discussions about RHEL subscriptions for testing; quiad "I haven't gotten too far with that ... still looking for the right person"; lots of people say that CentOS should be god enough for testing normally; but having some testboxes with RHEL around might be helpful === Full meeting log === See https://www.redhat.com/archives/epel-devel-list/2007-May/msg00088.html == Stats == === General === Number of EPEL Contributors 74 We welcome 13 new contributors: dcm_AT_acm.org, dev_AT_nigelj.com, eric.tanguy_AT_univ-nantes.fr, fedora_AT_theholbrooks.org, frank-buettner_AT_gmx.net, gajownik_AT_gmail.com, gilboad_AT_gmail.com, jeff.gilchrist_AT_gmail.com, jwb_AT_redhat.com, lxtnow_AT_gmail.com, mfleming+rpm_AT_enlartenment.com, ruben_AT_rubenkerkhof.com, trond.danielsen_AT_gmail.com === EPEL 5 === Number of source packages: 274 Number of binary packages: 437 There are 49 new Packages: * autodir | Creates user directories on demand * cgdb | CGDB is a curses-based interface to the GNU Debugger (GDB) * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * drgeo | Interactive educational geometry software * freehdl | GPLed free VHDL * gperiodic | Program for browsing the periodic table * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * incron | Inotify cron system * ircd-hybrid | Internet Relay Chat Server * libiptcdata | IPTC tag library * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * nrpe | Host/service/network monitoring agent for Nagios * ocaml | Objective Caml compiler and programming environment * pdns | A modern, advanced and high performance authoritative-only nameserver * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-DBD-SQLite | Self Contained RDBMS in a DBI Driver * perl-HTML-Table | Create HTML tables using simple interface * perl-IO-Multiplex | IO-Multiplex module for perl * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * php-channel-phpunit | Adds phpunit channel to PEAR * php-pear-DB | PEAR: Database Abstraction Layer * php-pear-Log | Abstracted logging facility for PHP * php-pecl-radius | Radius client library * php-pecl-xdebug | PECL package for debugging PHP scripts * Pound | Reverse proxy and load balancer * python-cheetah | Template engine and code-generator * python-docutils | A system for processing plaintext documentation * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * python-protocols | Open Protocols and Component Adaptation for Python * python-sqlite2 | DB-API 2.0 interface for SQLite 3.x * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * ushare | UPnP (TM) A/V Media Server * windowlab | Small and Simple Amiga-like Window Manager * yum-arch | Extract headers from rpm in a old yum repository === EPEL 4 === Number of source packages: 186 Number of binary packages: 348 There are 28 new Packages: * bugzilla | Bug tracking system * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * freehdl | GPLed free VHDL * gperiodic | Program for browsing the periodic table * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * ircd-hybrid | Internet Relay Chat Server * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * ocaml | Objective Caml compiler and programming environment * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-HTML-Table | Create HTML tables using simple interface * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * Pound | Reverse proxy and load balancer * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * windowlab | Small and Simple Amiga-like Window Manager From dwmw2 at infradead.org Sun May 20 12:31:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 20 May 2007 13:31:03 +0100 Subject: packages that could need ExclusiveArch updated In-Reply-To: <20070517202733.GA6900@nostromo.devel.redhat.com> References: <20070517202733.GA6900@nostromo.devel.redhat.com> Message-ID: <1179664263.8438.40.camel@shinybook.infradead.org> On Thu, 2007-05-17 at 16:27 -0400, Bill Nottingham wrote: > The following packages have ExcludeArch: ppc, but not ExcludeArch: ppc64. This > may need adjusted if they want to build in the future: > > 915resolution > alsa-tools > glest > gnome-applet-sensors > google-perftools > mono-debugger > stripesnoop > xeuphoric > xfce4-sensors-plugin Some of those I don't see listed at https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-ExcludeArch-ppc If you add ExcludeArch: ppc64, please make sure you _also_ add the bug to the FE-ExcludeArch-ppc64 tracker. -- dwmw2 From dwmw2 at infradead.org Sun May 20 12:32:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 20 May 2007 13:32:18 +0100 Subject: packages that could need ExclusiveArch updated In-Reply-To: <200705172025.16801.dennis@ausil.us> References: <20070517202733.GA6900@nostromo.devel.redhat.com> <200705172025.16801.dennis@ausil.us> Message-ID: <1179664339.8438.43.camel@shinybook.infradead.org> On Thu, 2007-05-17 at 20:25 -0500, Dennis Gilmore wrote: > I'd much rather see these use ExclusiveArch: x86_64 %{ix86} so they dont have > issues for people building on other archs. im assuming the reason ppc is > excluded is due to endianess issues No, endianness is a trivial issue which the package maintainer should fix up for themselves. None of our maintainers are _so_ lax that they just exclude PPC just for that, as far as I'm aware. The majority of the packages on the FE-ExcludeArch-ppc tracker aren't trivial issues which the package maintainer should necessarily handle for themselves. -- dwmw2 From petersen at redhat.com Sun May 20 13:58:51 2007 From: petersen at redhat.com (Jens Petersen) Date: Sun, 20 May 2007 23:58:51 +1000 Subject: cvs-import.sh still creates tags ending at fc7 In-Reply-To: <464DCAD3.7070503@hhs.nl> References: <464DCAD3.7070503@hhs.nl> Message-ID: <4650541B.4070707@redhat.com> Hans de Goede wrote: > The subject says it all I just imported 2 new packages with > cvs-import.sh and it created xxx_fc7 tags in the devel dir of those > packages, whereas make tag does do the right thing. BTW I just committed a change to cvs-import.sh for now that stops it from tagging imports, since the tagging breaks apparently when importing the same srpm (nvr) into a branch. (Perhaps someone can improve the script later to do the tagging right in every case.) So now after updating common/ one now needs to run "make tag" after importing an srpm, which incidently is how the process is already documented on the Wiki. Jens From nicolas.mailhot at laposte.net Sun May 20 14:09:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 20 May 2007 16:09:12 +0200 Subject: cvs-import.sh still creates tags ending at fc7 In-Reply-To: <4650541B.4070707@redhat.com> References: <464DCAD3.7070503@hhs.nl> <4650541B.4070707@redhat.com> Message-ID: <1179670152.29736.5.camel@rousalka.dyndns.org> Le dimanche 20 mai 2007 ? 23:58 +1000, Jens Petersen a ?crit : > Hans de Goede wrote: > > The subject says it all I just imported 2 new packages with > > cvs-import.sh and it created xxx_fc7 tags in the devel dir of those > > packages, whereas make tag does do the right thing. > > BTW I just committed a change to cvs-import.sh for now that stops it > from tagging imports, And you just broke my workflow Please keep the old behaviour. Or fix cvs-import tag creation logic but do not remove a feature just because it misbehaves for you. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Jochen at herr-schmitt.de Sun May 20 17:43:06 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 20 May 2007 19:43:06 +0200 Subject: Request for comaintainers In-Reply-To: <464AE3CE.9020006@city-fan.org> References: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> <464AE3CE.9020006@city-fan.org> Message-ID: <0ML31I-1HppSu1kPw-0004Dy@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 16 May 2007 11:58:22 +0100, you wrote: >This is probably a manifestation of http://bugzilla.redhat.com/190886 - >it's somewhat amazing that this bug is still unfixed upstream if my >diagnosis is correct. Yes you are right. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGUIi8T2AHK6txfgwRAkOfAKC5tl/xWSrurkqcrSHJJpBvh+lJrwCgzpTa 3onUl5da1SQNwPbS1J+Y9uY= =iWHN -----END PGP SIGNATURE----- From Jochen at herr-schmitt.de Sun May 20 17:56:41 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 20 May 2007 19:56:41 +0200 Subject: Request for comaintainers In-Reply-To: References: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> Message-ID: <0ML21M-1Hppg51geE-0006r0@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 16 May 2007 02:30:57 +0200, you wrote: >I have some interest in stellarium but i know less others ones... >(i will quick look some of them...) I will enter you as an comaintainer for stellarium. >PS: About kyum, Someone on the french forum reported that it has >deleted my repository definition: kwizart.repo. I will sanity check >it ... But i'm not a kde user usually... That is an upstreamm bug. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGUIvtT2AHK6txfgwRAp6kAKCRmUcls/q0x4HsQ7dZIVACSUKdzQCgi05G h0XP6uLrXCVajSZAWf0baXU= =fxpk -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Sun May 20 14:10:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 20 May 2007 16:10:18 +0200 Subject: FESCo Meeting Summary for 2007-05-10 In-Reply-To: <464AAE76.1070109@leemhuis.info> References: <1179281612.5749.0.camel@lincoln> <464AAE76.1070109@leemhuis.info> Message-ID: <20070520141018.GB16848@neu.nirvana> On Wed, May 16, 2007 at 09:10:46AM +0200, Thorsten Leemhuis wrote: > Hi All! > > On 16.05.2007 04:13, Brian Pepple wrote: > > > = EPEL Repotag = > > * Thorsten Leemhuis wanted FESCo members opinion regarding the use > > of repotags. The general concensus from the members present was > > that they didn't care for them. > > Sorry, but from looking at the full logs with statements like Sorry, thl/knurd/whatever, but trimming off all parts of the irc log, but the ones you want always give the wrong impression. Looking into the irc log one reads for example: | knurd reads the current discussion as "most FESCo members see no sense in repotags or don't care" So Brian more or less copied your own words into the summary and you object to that now? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Sun May 20 18:44:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 May 2007 20:44:55 +0200 Subject: FESCo Meeting Summary for 2007-05-10 In-Reply-To: <20070520141018.GB16848@neu.nirvana> References: <1179281612.5749.0.camel@lincoln> <464AAE76.1070109@leemhuis.info> <20070520141018.GB16848@neu.nirvana> Message-ID: <46509727.3080400@leemhuis.info> On 20.05.2007 16:10, Axel Thimm wrote: > On Wed, May 16, 2007 at 09:10:46AM +0200, Thorsten Leemhuis wrote: >> On 16.05.2007 04:13, Brian Pepple wrote: >>> = EPEL Repotag = >>> * Thorsten Leemhuis wanted FESCo members opinion regarding the use >>> of repotags. The general concensus from the members present was >>> that they didn't care for them. >> Sorry, but from looking at the full logs with statements like > Sorry, thl/knurd/whatever, but trimming off all parts of the irc log, > but the ones you want always give the wrong impression. Looking into > the irc log one reads for example: > > | knurd reads the current discussion as "most FESCo members see no sense in repotags or don't care" > > So Brian more or less copied your own words into the summary and you > object to that now? More or less yes; but the "less" is the point here: 1. [...] most FESCo members see no sense in repotags or don't care 2. [...] from the members present was that they didn't care for them The "see no sense" part is missing in the summary and IMHO relevant. Cu thl From Jochen at herr-schmitt.de Sun May 20 21:32:36 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Sun, 20 May 2007 23:32:36 +0200 Subject: Request for comaintainers In-Reply-To: References: <0ML29c-1HnyQa0qcT-0002iz@mrelayeu.kundenserver.de> Message-ID: <0ML31I-1Hpt1t1u1j-00044v@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 16 May 2007 02:30:57 +0200, you wrote: >I will start to do some work with these version on x86_64... >(quite sure there is a need to break the deep freeze about this >package and x86_64 support...) I have create a package for blender 2.44. You may find in on http://koji.fedoraproject.org/koji/buildinfo?buildID=6862 if you will find any bug please feel free to contact me. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGUL6kT2AHK6txfgwRAu10AKDyxlj46ugtVq3L0eOSPm31KqG1NwCgztR6 zqehdnIDp81QiT6nY7+iPbs= =9pcg -----END PGP SIGNATURE----- From pertusus at free.fr Sun May 20 22:44:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 21 May 2007 00:44:51 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179362111.2746.311.camel@localhost.localdomain> References: <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <1179362111.2746.311.camel@localhost.localdomain> Message-ID: <20070520224451.GB11171@free.fr> On Wed, May 16, 2007 at 05:35:11PM -0700, Toshio Kuratomi wrote: > The static-libs naming was resolved on list with no guidelines changes > needing to be made. I was not referring to the static-libs naming itself but to the following discussion, starting approximately at https://www.redhat.com/archives/fedora-packaging/2007-April/msg00185.html > The static library thread basically came to the same place that we are > at here. You have to follow the Guidelines. The reasons that the > guidelines are written as they are is in Ralf's email and in this > current exchange. By following the Guidelines you can help get them to > change. I can't see how. I can lose a lot of time I could devote to other tasks, however. > Bypassing the guidelines as you are doing is just going to lead us to > Packaging Armageddon with each rule being violated by those that > disagree with it. This has to stop. I agree that guidelines should be followed in general, but not at all cost. > Express an example of silliness and present a draft with the example as > something that should be allowed. However, the attitude that there are > some changes that are too silly to be recorded in the changelog is > exactly why the people that voted for the changelog guideline voted for > it. You are violating the spirit of the guideline as well as the letter > by not putting a changelog entry in and I think your draft, example, and > arguments will have to be very persuasive in order to make a change to > this guideline. Honestly for this example I thought I wasn't really violating the guideline and it was implicitly ok to avoid some changelog entries as the reverse seems so unnatural and bureaucratic to me. Moreover I have seen a lot of other packagers doing that while reading the commit messages without anybody complaining, so I thought it was ok, I stand corrected. This is very different from static libs, for which I deliberatly violate the guidelines. > > I always said that I agreed to report to FESCo that I ship a static lib, > > but that it was silly to ask FESCo when I know better, and I won't do it. > > > Then you are not in compliance with the guidelines. The Packaging > Committee itself has no teeth to enforce them. FESCo will have to > decide if it wants to enforce the guidelines, delegate that power, or > let the guidelines be informational rather than binding. It seems that the issue of reporting voluntary violations of the guidelines and how things are settled in that case to be more or less solved, and indeed this is a good thing to know how the 'justice' part of Fedora is working, I think it was lacking before. > Not true. A Makefile can do whatever it wants. A spec file is also > just a shell script when it comes down to it. Of course it can. But if there is a package not using -l to link it is a serious bug already. And having static libs in -static subpackages means that it really cannot happen, this point is moot. > > I did it without success. > No. You did it without succeeding in getting the guidelines changed. > You have a minority opinion. So you have to do some legwork to get the > majority to come over to your viewpoint. The most effective way to do > that in this case is not to write arguments to the mailing list. The > most effective way is to follow the guidelines and thereby amass a body > of packaging that supports your statements and shows what changes need > to be written into the guidelines. I don't have time, nor will to do that kind of work. I have arguments nobody responds to, I don't need to give number or evidences. > You claim that the guidelines should be changed to allow numerical > libraries to ship static libs but I can honestly say that FESCo has not > been asked to allow one numerical library to ship a static library since > the guideline went into effect. By bypassing the guidelines you're > making it so we are unaware of the problems with the guidelines and > denying us the data to change the guidelines to be better. I have always said, and I'll say it once more that I was ready to give the data, not to ask for permission. > We've left a door wide open for you to effect a change. Write a letter > that says "These are numerical libraries, ie, ones that [Distinguishing > features that make them relevant to this discussion]. As such they > should be allowed to (ship|link) a static library." Take your list of > libraries from above and add them to the form letter. Send it to FESCo > as a reply to "Plan for tomorrows (20070517) FESCO meeting" as an agenda > item like "Packages needing static libraries". Then FESCo or the > Packaging Committee can evaluate the magnitude of the problem and > attempt to reword the guideline to accommodate them. I am not going to do that bureaucratic stuff if there is no > Once that's done, write another letter that says "These libraries have > no shared libraries upstream. Thus they need to ship static libraries." > and repeat. Are you really meaning that the guideline (that is asking FESCo for static libs inclusion) is also in order for packages that ship only static libs. Once again it seems so weird to me that I figured that it wasn't needed. > There are several things that can result from this: > > 1) Your reasons for thinking these libraries are special won't be seen > by FESCo so they'll be denied. (Be sure to make your arguments > persuasive and descriptive and if possible show up for the meeting where > this is discussed :-) I have never used IRC and I definitvely haven't time to do that. As for persuasion there was a long thread on -devel I always refer to and so far nobody had a counter-argument. One can say that he isn't convinced without rational arguments, even a collective body can. But in that case I don't feel bound to that decision and I will violate it, that's rpecisely how I perceive the case of static libs currently. > 2) FESCo will simply allow the libraries through without a fuss. You're > neither better off nor worse off than before. Except for all the unneeded work done, although there are arguments that were already made (with great effort and time loss). > 3) FESCo will not want to deal with this everytime a numerical library > is reviewed. Seeing that you've extracted the important bits that > define a numerical library and why it is in need of static libraries, > they'll forward it on to the packaging committee to revise the > guidelines so they don't have to deal with approving libraries of these > types anymore. I don't have time to go through 'define a numerical library' I have already a reference to a thread explaining 'why it is in need of static libraries', so I don't think things willl change magically. > Nobody likes to do more work than they have to. Assuming your > description of what makes the libraries in question deserving of > shipping in static form is sufficient to show why and how the rules can > be amended to allow the kind of libraries you are requesting through, I > can't imagine that FESCo won't send the definition of numerical library > on to the Packaging Committee. It is, after all, why the rules were > drafted the way they are. My mail on the packaging list was unanswered (or more precisely, the points about static libs were unnanswered), I can't see why it will be different this time. To summarize my point, I think that what you propose above is burrying the issue in a lot of bureaucratic work, although there is already an unnanswered technical argument, that was already a lot of work to bring up in a long thread. I prefer being punished than go through the work you propose -- as long as nobody has answered my technical point. If somebody has something relevant to say on the subject of the libs that don't need dynamic linking and need portability I may reconsider my position, however. -- Pat From pertusus at free.fr Sun May 20 22:51:56 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 21 May 2007 00:51:56 +0200 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179383601.4735.822.camel@mccallum.corsepiu.local> References: <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <1179383601.4735.822.camel@mccallum.corsepiu.local> Message-ID: <20070520225156.GC11171@free.fr> On Thu, May 17, 2007 at 08:33:21AM +0200, Ralf Corsepius wrote: > I repeatedly answered to your concerns. No, never. > To reiterate: > * I don't see any technical reason for inclusion of any static library > in a distribution. Your primary argument "numerical programs" is a > non-argument - You simply are in error. This was not the conclusion of the thread started here: https://www.redhat.com/archives/fedora-devel-list/2006-November/msg00713.html > * Exceptions from this are not FPC's business, but are a > political/management issue, which should be decided by a management > entity. The guidelines reflect this notion by forcing packages to > redirect such decisions to FESCo. They are definitely not political issues, they may be management issues. Anyway I prefer what seems to be agreed more generally about what to do in case of guidelines violations started in another thread. -- Pat From petersen at redhat.com Mon May 21 00:41:43 2007 From: petersen at redhat.com (Jens Petersen) Date: Mon, 21 May 2007 10:41:43 +1000 Subject: cvs-import.sh still creates tags ending at fc7 In-Reply-To: <1179670152.29736.5.camel@rousalka.dyndns.org> References: <464DCAD3.7070503@hhs.nl> <4650541B.4070707@redhat.com> <1179670152.29736.5.camel@rousalka.dyndns.org> Message-ID: <4650EAC7.2090001@redhat.com> Nicolas Mailhot ????????: > Le dimanche 20 mai 2007 ? 23:58 +1000, Jens Petersen a ?crit : >> Hans de Goede wrote: >>> The subject says it all I just imported 2 new packages with >>> cvs-import.sh and it created xxx_fc7 tags in the devel dir of those >>> packages, whereas make tag does do the right thing. >> BTW I just committed a change to cvs-import.sh for now that stops it >> from tagging imports, > > And you just broke my workflow Oh, sorry about that. I reverted the change. > Please keep the old behaviour. Or fix cvs-import tag creation logic but > do not remove a feature just because it misbehaves for you. So does tagging with %dist work correctly now in branches from the import script? Jens From ajackson at redhat.com Mon May 21 15:16:51 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 21 May 2007 11:16:51 -0400 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <20070519163244.4cd70e5b.bugs.michael@gmx.net> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> <20070519163244.4cd70e5b.bugs.michael@gmx.net> Message-ID: <1179760611.18583.29.camel@localhost.localdomain> On Sat, 2007-05-19 at 16:32 +0200, Michael Schwendt wrote: > On Sat, 19 May 2007 16:11:15 +0200, Denis Leroy wrote: > > > >> # Like this > > >> ## or this in many script languages. > > >> > > >>> I remember a few years ago I was asked to remove all '# comments' > > >>> lines from scriptlets apparently because they "could cause problems"... > > >> > > >> No. You were only asked to not add such comment lines _after_ scriptlet > > >> sections in the spec file, because the comments would be included in the > > >> scriptlet bodies, even if a scriptlet section is passed to > > >> /sbin/ldconfig, > > >> which doesn't understand the contents and breaks badly. > > > > Not enough coffee. You meant "after scriptlet sections ON THE SAME LINE" > > as in > > > > %post -p /sbin/ldconfig # bad comment > > That one would not even rpmbuild. ;) > > > Rule of thumb: Avoid comment lines after %post/postun/pre/preun (and likely > also the trigger sections) up to the next non-scriptlet section. Is anyone reporting these as "things we shouldn't have to care about" to rpm-maint@ or the appropriate bugzilla? - ajax From jkeating at redhat.com Mon May 21 15:45:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 May 2007 11:45:53 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179545706.4735.1042.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705181234.32520.jkeating@redhat.com> <1179545706.4735.1042.camel@mccallum.corsepiu.local> Message-ID: <200705211145.53907.jkeating@redhat.com> On Friday 18 May 2007 11:35:06 pm Ralf Corsepius wrote: > > That page isn't linked to by anything. > > Irrelevant and a weak excuse - It's bug. > > Any program that segfaults, triggers "divisions by zero" or a > "stack-trace" is upon invalid input is broken. > > > ? You'd have to manually type that url in to get that error. > > Happens if you search koji.fedoraproject.org with a browser. So file a bug with our Trac page. http://hosted.fedoraproject.org/projects/koji Better yet, include a patch. Or maybe we should just stop doing anything else until we fix this little bug of yours. That's more important than anything else right? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon May 21 15:46:35 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 May 2007 11:46:35 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <409676c70705200337i61370d56wdea5ccb515f4fea9@mail.gmail.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <20070518141343.GA22296@ryvius.pekin.waw.pl> <409676c70705200337i61370d56wdea5ccb515f4fea9@mail.gmail.com> Message-ID: <200705211146.35593.jkeating@redhat.com> On Sunday 20 May 2007 6:37:33 am Trond Danielsen wrote: > I also agree. I think that an optional --wait flag make more sense. I > usually do not want to sit around and wait for the build to finish, so > I instantly press Ctrl-c to stop watching the build. I don't disagree that there should be. There just _isn't_ one right now. Patches accepted. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikeb at redhat.com Mon May 21 16:12:13 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 21 May 2007 12:12:13 -0400 Subject: certificate check bug in Makefile.common In-Reply-To: <1179511485.24886.17.camel@aglarond.local> References: <200705182040.58551.ville.skytta@iki.fi> <1179511485.24886.17.camel@aglarond.local> Message-ID: <1179763934.9260.1.camel@burren.boston.redhat.com> On Fri, 2007-05-18 at 14:04 -0400, Jeremy Katz wrote: > On Fri, 2007-05-18 at 20:40 +0300, Ville Skytt? wrote: > > There appears to be a bug in the certificate check in Makefile.common: > [snip] > > The attached patch should fix it. > > Thanks, applied > > > Also, I wonder if it'd be better to check > > $HOME/.koji/client.crt instead of ~/.fedora.cert? > > The reason we don't is that we use ~/.fedora.cert as the cert with curl > when doing uploads. Ultimately, we should get to having one place for > this... The latest version of fedora-packager-setup.sh will generate a ~/.koji/config that points to ~/.fedora.cert and ~/.fedora-*-ca.cert. No more duplicate copies of certificates. From rc040203 at freenet.de Mon May 21 16:15:56 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 21 May 2007 18:15:56 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705211145.53907.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705181234.32520.jkeating@redhat.com> <1179545706.4735.1042.camel@mccallum.corsepiu.local> <200705211145.53907.jkeating@redhat.com> Message-ID: <1179764156.4735.1292.camel@mccallum.corsepiu.local> On Mon, 2007-05-21 at 11:45 -0400, Jesse Keating wrote: > On Friday 18 May 2007 11:35:06 pm Ralf Corsepius wrote: > > > That page isn't linked to by anything. > > > > Irrelevant and a weak excuse - It's bug. > > > > Any program that segfaults, triggers "divisions by zero" or a > > "stack-trace" is upon invalid input is broken. > > > > > You'd have to manually type that url in to get that error. > > > > Happens if you search koji.fedoraproject.org with a browser. > > So file a bug with our Trac page. > http://hosted.fedoraproject.org/projects/koji > > Better yet, include a patch. So you finally accept that this is a bug? So far you have been rigorously refusing to accept this fact and tried to escape by weak excuses ... > Or maybe we should just stop doing anything else > until we fix this little bug of yours. That's more important than anything > else right? ..., somebody it please hit this guy with a clue stick! Ralf From jkeating at redhat.com Mon May 21 16:26:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 May 2007 12:26:51 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179764156.4735.1292.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> Message-ID: <200705211226.51602.jkeating@redhat.com> On Monday 21 May 2007 12:15:56 pm Ralf Corsepius wrote: > > Better yet, include a patch. > > So you finally accept that this is a bug? So far you have been > rigorously refusing to accept this fact and tried to escape by weak > excuses ... Bug or not, the point I was trying to make is that this is trivial and pointless to be arguing over. So it's a "bug". So what? Do you really want to spend X amount of time and emails on such a trivial thing? File a ticket and move on. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Mon May 21 16:27:58 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 21 May 2007 12:27:58 -0400 Subject: Fedora Bugzilla Merge Plan In-Reply-To: <464E0C1C.2030700@redhat.com> References: <464E0C1C.2030700@redhat.com> Message-ID: <4651C88E.5090106@redhat.com> Warren Togami wrote: > What Will Happen? > ================= > "Fedora Core" and "Fedora Extras" Bugzilla products will merge into a > single product named "Fedora". All Versions and components of the > previous two products will exist in the new combined product, then all > bugs will be migrated. > > dkl will make this change without any mail being sent. I hope that we > can aim for Monday, May 21st EDT night to make this change. > > Other Things Needing to be Fixed? > ================================= > 1) Canned Queries of Bugzilla in various scripts and URL's > 2) Package Review submission template > 3) owners.list and owners-sync script > > Anything else people can think of that needs fixing to cope with this > Bugzilla change? > dkl said that he would prefer to do this next week. So this will be postponed for now. Warren From rc040203 at freenet.de Mon May 21 16:35:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 21 May 2007 18:35:32 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705211226.51602.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> Message-ID: <1179765332.4735.1297.camel@mccallum.corsepiu.local> On Mon, 2007-05-21 at 12:26 -0400, Jesse Keating wrote: > On Monday 21 May 2007 12:15:56 pm Ralf Corsepius wrote: > > > Better yet, include a patch. > > > > So you finally accept that this is a bug? So far you have been > > rigorously refusing to accept this fact and tried to escape by weak > > excuses ... > > Bug or not, the point I was trying to make is that this is trivial and > pointless to be arguing over. So it's a "bug". And why haven't you fixed it? > So what? Do you really want > to spend X amount of time and emails on such a trivial thing? And why haven't you fixed it? > File a ticket and move on. File the ticket yourselves. Takes longer for me to file the ticket than it would have taken you to fix it. Ralf From mclasen at redhat.com Mon May 21 16:33:38 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 21 May 2007 12:33:38 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179765332.4735.1297.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> Message-ID: <1179765218.4062.3.camel@dhcp83-33.boston.redhat.com> On Mon, 2007-05-21 at 18:35 +0200, Ralf Corsepius wrote: > > File a ticket and move on. > File the ticket yourselves. Takes longer for me to file the ticket than > it would have taken you to fix it. So, your time is too costly to file a bug, but you can bitch about this on the mailing list for days ? Time for a vacation ? From mikeb at redhat.com Mon May 21 16:38:58 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 21 May 2007 12:38:58 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <1179765332.4735.1297.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> Message-ID: <1179765538.16244.1.camel@burren.boston.redhat.com> On Mon, 2007-05-21 at 18:35 +0200, Ralf Corsepius wrote: > On Mon, 2007-05-21 at 12:26 -0400, Jesse Keating wrote: > > On Monday 21 May 2007 12:15:56 pm Ralf Corsepius wrote: > > > > Better yet, include a patch. > > > > > > So you finally accept that this is a bug? So far you have been > > > rigorously refusing to accept this fact and tried to escape by weak > > > excuses ... > > > > Bug or not, the point I was trying to make is that this is trivial and > > pointless to be arguing over. So it's a "bug". > And why haven't you fixed it? > > > So what? Do you really want > > to spend X amount of time and emails on such a trivial thing? > And why haven't you fixed it? > > > File a ticket and move on. > File the ticket yourselves. Takes longer for me to file the ticket than > it would have taken you to fix it. I'm responsible for the web UI. What should it be doing in this case? You gave the page invalid input, and it told you you gave it invalid input. Just because the error page isn't pretty, doesn't mean it's doing something incorrect. From katzj at redhat.com Mon May 21 16:40:08 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 21 May 2007 12:40:08 -0400 Subject: certificate check bug in Makefile.common In-Reply-To: <1179763934.9260.1.camel@burren.boston.redhat.com> References: <200705182040.58551.ville.skytta@iki.fi> <1179511485.24886.17.camel@aglarond.local> <1179763934.9260.1.camel@burren.boston.redhat.com> Message-ID: <1179765608.24269.14.camel@aglarond.local> On Mon, 2007-05-21 at 12:12 -0400, Mike Bonnet wrote: > On Fri, 2007-05-18 at 14:04 -0400, Jeremy Katz wrote: > > The reason we don't is that we use ~/.fedora.cert as the cert with curl > > when doing uploads. Ultimately, we should get to having one place for > > this... > > The latest version of fedora-packager-setup.sh will generate a > ~/.koji/config that points to ~/.fedora.cert and ~/.fedora-*-ca.cert. > No more duplicate copies of certificates. Awesome, thanks Mike Jeremy From mmcgrath at redhat.com Mon May 21 16:42:47 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 May 2007 11:42:47 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179765332.4735.1297.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> Message-ID: <4651CC07.3010003@redhat.com> Ralf Corsepius wrote: > On Mon, 2007-05-21 at 12:26 -0400, Jesse Keating wrote: > >> On Monday 21 May 2007 12:15:56 pm Ralf Corsepius wrote: >> >>>> Better yet, include a patch. >>>> >>> So you finally accept that this is a bug? So far you have been >>> rigorously refusing to accept this fact and tried to escape by weak >>> excuses ... >>> >> Bug or not, the point I was trying to make is that this is trivial and >> pointless to be arguing over. So it's a "bug". >> > And why haven't you fixed it? > > >> So what? Do you really want >> to spend X amount of time and emails on such a trivial thing? >> > And why haven't you fixed it? > > >> File a ticket and move on. >> > File the ticket yourselves. Takes longer for me to file the ticket than > it would have taken you to fix it. > > Ralf, I'm sorry but you have been horribly disrespectful in this thread and in others. Its time dood. move on. http://www.ubuntu.com/community/participate -Mike From rc040203 at freenet.de Mon May 21 16:52:20 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 21 May 2007 18:52:20 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179765218.4062.3.camel@dhcp83-33.boston.redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> <1179765218.4062.3.camel@dhcp83-33.boston.redhat.com> Message-ID: <1179766340.4735.1306.camel@mccallum.corsepiu.local> On Mon, 2007-05-21 at 12:33 -0400, Matthias Clasen wrote: > On Mon, 2007-05-21 at 18:35 +0200, Ralf Corsepius wrote: > > > > File a ticket and move on. > > File the ticket yourselves. Takes longer for me to file the ticket than > > it would have taken you to fix it. > > So, your time is too costly to file a bug, but you can bitch about this > on the mailing list for days ? Nope, it's time to show Keating his frontiers. 1st rel-eng deploys immature SW, then he excuses bugs with "dev absend", then he tried to deny the fact this is a bug. Then he starts to push around people. Put youself into a contributors position: Is this collaboration? Is this customer friendliness? > Time for a vacation ? >From Fedora, yes, probably - I am getting to close. Ralf From rc040203 at freenet.de Mon May 21 16:55:17 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 21 May 2007 18:55:17 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <4651CC07.3010003@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> <4651CC07.3010003@redhat.com> Message-ID: <1179766518.4735.1309.camel@mccallum.corsepiu.local> On Mon, 2007-05-21 at 11:42 -0500, Mike McGrath wrote: > Ralf Corsepius wrote: > Ralf, I'm sorry but you have been horribly disrespectful in this thread > and in others. Its time dood. move on. > > http://www.ubuntu.com/community/participate > > -Mike I do show respect to those who deserve it. Ralf From trond.danielsen at gmail.com Mon May 21 17:09:45 2007 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Mon, 21 May 2007 19:09:45 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <200705211146.35593.jkeating@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <20070518141343.GA22296@ryvius.pekin.waw.pl> <409676c70705200337i61370d56wdea5ccb515f4fea9@mail.gmail.com> <200705211146.35593.jkeating@redhat.com> Message-ID: <409676c70705211009w40137627q1cb3826570ba97c5@mail.gmail.com> 2007/5/21, Jesse Keating : > On Sunday 20 May 2007 6:37:33 am Trond Danielsen wrote: > > I also agree. I think that an optional --wait flag make more sense. I > > usually do not want to sit around and wait for the build to finish, so > > I instantly press Ctrl-c to stop watching the build. > > I don't disagree that there should be. There just _isn't_ one right now. > Patches accepted. Could it be as simple as this? ftp://open-gnss.org/pub/fedora/0001-Changed-from-wait-as-default-to-nowait-behaviour.patch -- Trond Danielsen From mmcgrath at redhat.com Mon May 21 17:17:00 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 May 2007 12:17:00 -0500 Subject: Broken upgrade paths in F7 In-Reply-To: <1179766518.4735.1309.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> <4651CC07.3010003@redhat.com> <1179766518.4735.1309.camel@mccallum.corsepiu.local> Message-ID: <4651D40C.3070108@redhat.com> Ralf Corsepius wrote: > On Mon, 2007-05-21 at 11:42 -0500, Mike McGrath wrote: > >> Ralf Corsepius wrote: >> > > >> Ralf, I'm sorry but you have been horribly disrespectful in this thread >> and in others. Its time dood. move on. >> >> http://www.ubuntu.com/community/participate >> >> -Mike >> > I do show respect to those who deserve it. > If you'd said that to me, I would have let it go. I will not, however, stand by while you say it about Jesse. He does deserve your respect. Here's why: 1) If anyone can explain how he does what he does while still being able to sleep every once in a while, let me know. 2) He's more modest about it but I am 90% sure the merge wouldn't have happened in F7 were it not for him. 3) Sponsor status. He sponsors more people than anyone else in fedora. 55 people! That's 5% of ALL Fedora contributors. 4) Pungi :) and this list is "what he's done lately :)" You can disagree with him, but the man's got skills. Everyone's doing very difficult work here. And AFAIK the merge is the type of work that has never been done in any community of this size in the world before. We make an operating system, and a good one. Telling people to do work is easy, doing the work and submitting it as a patch is not. -Mike From Christian.Iseli at licr.org Mon May 21 17:05:53 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Mon, 21 May 2007 19:05:53 +0200 Subject: Fedora Package Status of May 21, 2007 Message-ID: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> Hi folks, Well, things are still pretty much in flux, but I tried to update the script to the current layout of things and produce some sort of report. Please take with a larger-than-usual grain of salt... I attempted to put the report on the wiki, but so far failed... so if anyone closer to the beast could upload the attached text in the page, that would be cool :-) Cheers, Christian ---- Fedora Package Status of May 21, 2007 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners file stats: - 4465 packages - 7342 binary rpms in devel - 98 orphans - 105 packages not available in devel or release Fedora at FamilleCollet dot com php-pear-Net-Ping Fedora at FamilleCollet dot com php-pear-Net-Traceroute allisson at gmail dot com clutter-gst allisson at gmail dot com clutter-gtk andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ddrescue andreas at bawue dot net perl-NetAddr-IP arnd at arndb dot de dtc bdpepple at ameritech dot net galago-filesystem bpepple at fedoraproject dot org purple-galago cgoorah at yahoo dot com dot au netgen chris dot stone at gmail dot com php-pear-File-Passwd chris dot stone at gmail dot com php-pear-HTML-QuickForm-ElementGrid chris dot stone at gmail dot com php-pear-File-SMBPasswd cweyl at alumni dot drew dot edu perl-Data-Visitor cweyl at alumni dot drew dot edu perl-Class-Data-Accessor cweyl at alumni dot drew dot edu perl-Catalyst-Runtime cweyl at alumni dot drew dot edu perl-Text-RecordParser cweyl at alumni dot drew dot edu perl-Class-Base cweyl at alumni dot drew dot edu perl-Config-Any cweyl at alumni dot drew dot edu perl-Class-C3-XS cweyl at alumni dot drew dot edu perl-JSON-XS cweyl at alumni dot drew dot edu perl-MooseX-Getopt cweyl at alumni dot drew dot edu perl-Text-SimpleTable cweyl at alumni dot drew dot edu perl-File-Modified cweyl at alumni dot drew dot edu perl-Catalyst-Plugin-ConfigLoader cweyl at alumni dot drew dot edu perl-Text-TabularDisplay cweyl at alumni dot drew dot edu perl-CGI-Prototype cweyl at alumni dot drew dot edu perl-Archive-Any cweyl at alumni dot drew dot edu perl-Declare-Constraints-Simple dakingun at gmail dot com referencer dbhole at redhat dot com dom2-core-tests dbhole at redhat dot com objectweb-anttask dcantrell at redhat dot com repoman devrim at commandprompt dot com postgresql-pgpool-II dgoodwin at dangerouslyinc dot com wuja fangqq at gmail dot com wqy-bitmap-fonts fedora at christoph-wickert dot de xfce4-places-plugin fedora at christoph-wickert dot de xfce4-verve-plugin foolish at guezz dot net arp-scan foolish at guezz dot net DMitry foolish at guezz dot net nbtscan foolish at guezz dot net perl-Net-Libdnet foolish at guezz dot net perl-libwhisker2 foolish at guezz dot net perl-DBIx-SQLite-Simple foolish at guezz dot net perl-Net-Pcap foolish at guezz dot net perl-Net-IPv4Addr foolish at guezz dot net perl-SQLite-Simple foolish at guezz dot net scratchpad foolish at guezz dot net perl-Class-Gomor foolish at guezz dot net ike-scan foolish at guezz dot net perl-Nmap-Parser foolish at guezz dot net halberd gauret at free dot fr pdftohtml green at redhat dot com ws-common-utils guillaume dot thouvenin at bull dot net elsa icon at fedoraproject dot org mod_evasive j dot w dot r dot degoede at hhs dot nl rott j dot w dot r dot degoede at hhs dot nl ants jhrozek at redhat dot com dwdiff jmp at safe dot ca clement jnovy at redhat dot com schismtracker johan at x-tnd dot be kftpgrabber jonathansteffan at gmail dot com plone jonathansteffan at gmail dot com zope jorton at redhat dot com libc-client jwboyer at jdub dot homelinux dot org gaim-meanwhile kmatsui at t3 dot rim dot or dot jp mcpp kwizart at gmail dot com python-BeautifulSoup lightsolphoenix at gmail dot com kio_p7zip lightsolphoenix at gmail dot com tastymenu limb at jcomserv dot net tiquit lmacken at redhat dot com python-TurboMail lxtnow at gmail dot com specto mastahnke at gmail dot com kflickr mastahnke at gmail dot com epel-release mastahnke at gmail dot com php-magpierss matthias at rpmforge dot net python-Coherence matthias at rpmforge dot net autodir matthias at rpmforge dot net python-tag maxime dot carron at fedoraproject dot org pypar2 mcepl at redhat dot com gstreamer-plugins-pulseaudio mclasen at redhat dot com liberation-fonts paul at all-the-johnsons dot co dot uk XaraLX paul at all-the-johnsons dot co dot uk mysql-connector-net pcheung at redhat dot com asm2 pertusus at free dot fr ivman rcritten at redhat dot com jss rdieter at math dot unl dot edu kde-settings roozbeh at farsiweb dot info perl-Math-Vec rpm at greysector dot net gsm ruben at rubenkerkhof dot com perl-Danga-Socket ruben at rubenkerkhof dot com perl-Sys-Syscall ruben at rubenkerkhof dot com perl-IO-AIO rvokal at redhat dot com pidgin-guifications steve at silug dot org perl-YAML-Syck steve at silug dot org perl-Pugs-Compiler-Rule steve at silug dot org perl-Image-Math-Constrain steve at silug dot org perl-YAML-Tiny steve at silug dot org perl-Affix-Infix2Postfix vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp walters at redhat dot com hippo-canvas walters at redhat dot com bigboard wart at kobold dot org tdom - 15 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=211737,212003,222191,231303,236162 perl-Class-Data-Accessor adpacifico at users.sourceforge.net mugshot otaylor at redhat.com eclipse bkonrath at redhat.com xmlunit pcheung at redhat.com kadischi jasperhartline at adelphia.net https://bugzilla.redhat.com/bugzilla/buglist.cgi?bug_id=217262,221084,221717,222347,224458,226725,227091,231861,235136,236091 tdom wart at kobold.org dkms Matt_Domsch at dell.com agg caolanm at redhat.com g-wrap notting at redhat.com libsilc wtogami at redhat.com netgen cgoorah at yahoo.com.au objectweb-anttask rafaels at redhat.com cyrus-imapd tjanouse at redhat.com lostirc splinux25 at gmail.com dolphin johan at x-tnd.be - 3 packages present in the development repo which have no owners entry gstreamer-plugins-pulse s390utils ws-commons-util - 5 orphaned packages, yet available in devel driftnet libedit luks-tools pam_usb udftools FE-ACCEPT packages stats: - 2426 accepted, closed package reviews - 67 accepted, closed package reviews not in repo - 7 accepted, closed package reviews not in owners - 108 accepted, open package reviews older than 4 weeks; - 129 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 239 open tickets - 152 tickets with no activity in four weeks - 22 closed tickets FE-NEW packages stats: - 1029 open tickets - 884 tickets with no activity in four weeks - 55 closed tickets FE-NEEDSPONSOR packages stats: - 52 open tickets - 26 tickets with no activity in four weeks FE-LEGAL packages stats: - 1 open tickets - 1 tickets with no activity in four weeks FE-GUIDELINES packages stats: - open tickets OPEN-BUGS packages stats: - 32 open tickets - 2 tickets with no activity in eight weeks - 19 tickets with no activity in four weeks CVS stats: - 4470 packages with a devel directory - 4 packages with no owners entry isorelax-0-0.1.release20050331.1jpp.1.src.rpm mysql-administrator postgis tdma - 195 packages were dropped from Fedora Maintainers stats: - 361 maintainers - 2 inactive maintainers with open bugs - 4 inactive maintainers Comps.xml files stats: - 2368 packages in comps-f7 file - 938 packages missing from comps-f7 file - 32 packages in comps-f7 but not in repo -------------- next part -------------- A non-text attachment was scrubbed... Name: PackageStatus.txt.gz Type: application/x-gzip Size: 74251 bytes Desc: not available URL: From bpepple at fedoraproject.org Mon May 21 17:30:25 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 21 May 2007 13:30:25 -0400 Subject: Broken upgrade paths in F7 In-Reply-To: <4651D40C.3070108@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> <4651CC07.3010003@redhat.com> <1179766518.4735.1309.camel@mccallum.corsepiu.local> <4651D40C.3070108@redhat.com> Message-ID: <1179768625.5832.5.camel@lincoln> On Mon, 2007-05-21 at 12:17 -0500, Mike McGrath wrote: > Ralf Corsepius wrote: > >> > > I do show respect to those who deserve it. > > > > If you'd said that to me, I would have let it go. I will not, however, > stand by while you say it about Jesse. He does deserve your respect. > Here's why: > > 1) If anyone can explain how he does what he does while still being able > to sleep every once in a while, let me know. > 2) He's more modest about it but I am 90% sure the merge wouldn't have > happened in F7 were it not for him. > 3) Sponsor status. He sponsors more people than anyone else in fedora. > 55 people! That's 5% of ALL Fedora contributors. > 4) Pungi :) > > and this list is "what he's done lately :)" +1000. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Mon May 21 18:32:30 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 22 May 2007 03:32:30 +0900 Subject: plague buildsys seems in disk shortage Message-ID: <4651E5BE.1070604@ioa.s.u-tokyo.ac.jp> Hello. I submitted 4 build queues of my packages to plague buildsys, however all of them failed due to disk shortage (perhaps). http://buildsys.fedoraproject.org/logs/fedora-6-extras/33524-cmigemo-1.3-0.3.c_MIT.fc6/x86_64/root.log Thank you in advance. Mamoru From bugs.michael at gmx.net Mon May 21 18:38:23 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 21 May 2007 20:38:23 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <4651D40C.3070108@redhat.com> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <200705211145.53907.jkeating@redhat.com> <1179764156.4735.1292.camel@mccallum.corsepiu.local> <200705211226.51602.jkeating@redhat.com> <1179765332.4735.1297.camel@mccallum.corsepiu.local> <4651CC07.3010003@redhat.com> <1179766518.4735.1309.camel@mccallum.corsepiu.local> <4651D40C.3070108@redhat.com> Message-ID: <20070521203823.552b02dc.bugs.michael@gmx.net> On Mon, 21 May 2007 12:17:00 -0500, Mike McGrath wrote: > Ralf Corsepius wrote: > > On Mon, 2007-05-21 at 11:42 -0500, Mike McGrath wrote: > > > >> Ralf Corsepius wrote: > >> > > > > > >> Ralf, I'm sorry but you have been horribly disrespectful in this thread > >> and in others. Its time dood. move on. > >> > >> http://www.ubuntu.com/community/participate > >> > >> -Mike > >> > > I do show respect to those who deserve it. > > > > If you'd said that to me, I would have let it go. I will not, however, > stand by while you say it about Jesse. He does deserve your respect. > Here's why: > > 1) If anyone can explain how he does what he does while still being able > to sleep every once in a while, let me know. > 2) He's more modest about it but I am 90% sure the merge wouldn't have > happened in F7 were it not for him. > 3) Sponsor status. He sponsors more people than anyone else in fedora. > 55 people! That's 5% of ALL Fedora contributors. Uh, come on, this thread is moving ridiculously close to the dark side of the force. Sponsoring Red Hat employees involves blanket-approval, we all know that, and you should know that you're comparing apples and oranges anyway. Or most likely you refer to sub-projects where community folks cannot sponsor anyone. You can look up Fedora Extras sponsor stats here for comparison, where Jesse is listed as sponsoring 14, and the reverse lookup will likely reveal they are @redhat.com, perhaps all: https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&role_type=sponsor&format=html From eric.tanguy at univ-nantes.fr Mon May 21 18:37:52 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 21 May 2007 20:37:52 +0200 Subject: Build problem for EPEL-4 Message-ID: <1179772672.8858.21.camel@bureau.maison> I tried to build some packages for EL-4 and all fail due to the same error : http://buildsys.fedoraproject.org/logs/fedora-4-epel/33515-ushare-0.9.7-2.el4/ppc/root.log From tcallawa at redhat.com Mon May 21 18:49:25 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 21 May 2007 13:49:25 -0500 Subject: [Guidelines Change] PHP Changes Message-ID: <1179773365.6254.252.camel@localhost.localdomain> Changes were made to http://fedoraproject.org/wiki/Packaging/PHP =========================== The php-common package In Fedora Core 6 and above (version 5.1.6-3.4) uses new virtual provides to ensure ABI compatility, and usefull macros to test for it (ref.: /etc/rpm/macros.php in php-devel.) The new versions provide: * php(api): PHP Api Version * php(zend-abi) : Zend Module Api No Older versions only provide: * php-api : PHP Api Version Therefore the guidelines for the PECL Requires section were updated to include the following information: {{{ %if %{?php_zend_api}0 Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} %else Requires: php-api = %{php_apiver} %endif Provides: php-pecl(foo) }}} This will ensure ABI compatiblity while also maintaining backwards compatibility with older versions of php. After FC-6 is deprecated, maintaining backwards compatiblity should no longer be required in the guidelines. The PEAR section just above the PECL section was also reformatted so that it is contained within wiki code blocks for consistency. =========================== The Macros and Scriptlets section of the PHP guidelines now has a versioned BuildRequires of: BuildRequires: php-pear >= 1:1.4.9-1.2 The reason for this is because the macros are only defined after this version. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227190 Bug #227190 for an example of how the current guidelines are confusing. From peter at thecodergeek.com Mon May 21 18:53:40 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 21 May 2007 11:53:40 -0700 (PDT) Subject: Broken upgrade paths in F7 Message-ID: <33750.65.223.36.19.1179773620.squirrel@webmail.thecodergeek.com> Michael Schwendt wrote: > Uh, come on, this thread is moving ridiculously close to the dark side of > the force. Sponsoring Red Hat employees involves blanket-approval, we all > know that, and you should know that you're comparing apples and oranges > anyway. Or most likely you refer to sub-projects where community folks > cannot sponsor anyone. You can look up Fedora Extras sponsor stats here > for comparison, where Jesse is listed as sponsoring 14, and the reverse > lookup will likely reveal they are @redhat.com, perhaps all: Still, this does not preclude Jesse from the respect he rightfully deserves, given his heavy leadership and involvement in so much of Fedora as a whole. As an aside, even *if* Jesse did not do as much (or anything!) as he does for the Fedora Project, he *STILL* deserves to be treated respectfully - *everyone* does. We're in this as a community, not as competitors. Disagreements and discussions of differing perspectives (whew - say _that_ three times fast ^_^) are good and healthy...so long as they're done with a mutual respect between the parties. -- Peter Gordon (codergeek42) This message was sent through a webmail interface, and thus not signed. From mmcgrath at redhat.com Mon May 21 19:07:30 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 21 May 2007 14:07:30 -0500 Subject: plague buildsys seems in disk shortage In-Reply-To: <4651E5BE.1070604@ioa.s.u-tokyo.ac.jp> References: <4651E5BE.1070604@ioa.s.u-tokyo.ac.jp> Message-ID: <4651EDF2.7060505@redhat.com> Mamoru Tasaka wrote: > Hello. > > I submitted 4 build queues of my packages to plague > buildsys, however all of them failed due to > disk shortage (perhaps). > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/33524-cmigemo-1.3-0.3.c_MIT.fc6/x86_64/root.log > > Thank you in advance. > > Mamoru I have disabled that builder, it should work now. -Mike From bugs.michael at gmx.net Mon May 21 19:17:34 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 21 May 2007 21:17:34 +0200 Subject: plague buildsys seems in disk shortage In-Reply-To: <4651E5BE.1070604@ioa.s.u-tokyo.ac.jp> References: <4651E5BE.1070604@ioa.s.u-tokyo.ac.jp> Message-ID: <20070521211734.9de4601e.bugs.michael@gmx.net> On Tue, 22 May 2007 03:32:30 +0900, Mamoru Tasaka wrote: > Hello. > > I submitted 4 build queues of my packages to plague > buildsys, however all of them failed due to > disk shortage (perhaps). > > http://buildsys.fedoraproject.org/logs/fedora-6-extras/33524-cmigemo-1.3-0.3.c_MIT.fc6/x86_64/root.log > > Thank you in advance. Please requeue. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon May 21 19:28:25 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 21 May 2007 21:28:25 +0200 Subject: [Guidelines Change] PHP Changes In-Reply-To: <1179773365.6254.252.camel@localhost.localdomain> References: <1179773365.6254.252.camel@localhost.localdomain> Message-ID: <20070521212825.77fd7f96@python3.es.egwn.lan> Tom "spot" Callaway wrote : > The new versions provide: > * php(api): PHP Api Version > * php(zend-abi) : Zend Module Api No > > Older versions only provide: > * php-api : PHP Api Version Unfortunately, I just noticed that the RHEL5 packages are "half way". The php-common package provides both : php-api = 20041225 php-zend-abi = 20050922 ...but no "php(zend-abi)" or "php(api)" versions of the same values. To make things easier for EPEL, I'll file a RFE for the next RHEL5 PHP update to provide those... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2948.fc6 Load : 0.56 0.63 0.63 From chris.stone at gmail.com Mon May 21 20:19:02 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 21 May 2007 13:19:02 -0700 Subject: Fedora Package Status of May 21, 2007 In-Reply-To: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> References: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> Message-ID: On 5/21/07, Christian Iseli wrote: > Hi folks, > > Well, things are still pretty much in flux, but I tried to update the > script to the current layout of things and produce some sort of report. > > Please take with a larger-than-usual grain of salt... FYI, the Top 30 BZ review requests reviewers section does not seem to be picking up my latest reviews like bug #227241 or #238367 From eric.tanguy at univ-nantes.fr Mon May 21 20:40:32 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Mon, 21 May 2007 22:40:32 +0200 Subject: Build problem for EPEL-4 In-Reply-To: <1179772672.8858.21.camel@bureau.maison> References: <1179772672.8858.21.camel@bureau.maison> Message-ID: <1179780032.8858.24.camel@bureau.maison> Le lundi 21 mai 2007 ? 20:37 +0200, Tanguy Eric a ?crit : > I tried to build some packages for EL-4 and all fail due to the same > error : > http://buildsys.fedoraproject.org/logs/fedora-4-epel/33515-ushare-0.9.7-2.el4/ppc/root.log > Someone could help me to understand why i have this building error with plague or epel4 : Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-ppc-epel-a343a52ceeb20dafb214d3b08f12dfa5dbc09a17/root install buildsys-build http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Mon, 21 May 2007 20:37:12 GMT Server: Apache/2.0.52 Content-Length: 342 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] No more mirrors to try. Cleaning up... The problem come from me or the system ? Thanks Eric From tcallawa at redhat.com Mon May 21 21:01:09 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 21 May 2007 16:01:09 -0500 Subject: [Guidelines Change] DistTag changes Message-ID: <1179781269.6254.259.camel@localhost.localdomain> The DistTag guidelines (found here: http://fedoraproject.org/wiki/Packaging/DistTag) have had some changes committed. There are some additional macros for DistTag that make it much easier to conditionalize inside of spec files. Two helper macros were added: %{fc#} and %{el#} (where # is the value of %{fedora} or %{rhel}, respectively). This means that if %{fedora} is set to 7, the following macro is set: %define fc7 1 This permits easier conditionalization in spec files. For example, with these defines, you can do: %{?el5: a} %{?el4: b} %{?fc7: Requires: foo} %{?fc6: Requires: bar} Without these macros, you have to resort to: %if "%rhel" == "5" a %endif %if "%rhel" == "4" b %endif %if "%rhel" == "3" c %endif %if "%rhel" == "2" d %endif Keep in mind the words of wise old Uncle Ben: With great power comes great responsibility. Use these conditional helper macros sparingly. Also, all references to "Fedora Core" or "Fedora Extras" were replaced by ninjas to "Fedora". ~spot From notting at redhat.com Mon May 21 21:09:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 May 2007 17:09:06 -0400 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <1179760611.18583.29.camel@localhost.localdomain> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> <20070519163244.4cd70e5b.bugs.michael@gmx.net> <1179760611.18583.29.camel@localhost.localdomain> Message-ID: <20070521210906.GJ2486@nostromo.devel.redhat.com> > Is anyone reporting these as "things we shouldn't have to care about" to > rpm-maint@ or the appropriate bugzilla? It's somewhat tricky to fix - you're asking rpm-the-parser to either a) elide anything that starts with '#' from all scriplets, even though it may be valid in some interpreter b) conditionally elide it based on what the scriplet interpreter is Not sure it's 100% worth the change from stupid-but-predictable. Bill From laurent.rineau__fedora_extras at normalesup.org Mon May 21 21:42:51 2007 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Mon, 21 May 2007 23:42:51 +0200 Subject: Broken upgrade paths in F7 In-Reply-To: <1179766340.4735.1306.camel@mccallum.corsepiu.local> References: <1179175371.19267.39.camel@vader.jdub.homelinux.org> <1179765218.4062.3.camel@dhcp83-33.boston.redhat.com> <1179766340.4735.1306.camel@mccallum.corsepiu.local> Message-ID: <200705212342.51840@rineau.tsetse> On Monday 21 May 2007 18:52:20 Ralf Corsepius wrote: > On Mon, 2007-05-21 at 12:33 -0400, Matthias Clasen wrote: > > On Mon, 2007-05-21 at 18:35 +0200, Ralf Corsepius wrote: > > > > File a ticket and move on. > > > > > > File the ticket yourselves. Takes longer for me to file the ticket than > > > it would have taken you to fix it. > > > > So, your time is too costly to file a bug, but you can bitch about this > > on the mailing list for days ? > > Nope, it's time to show Keating his frontiers. > > 1st rel-eng deploys immature SW, then he excuses bugs with "dev absend", > then he tried to deny the fact this is a bug. Then he starts to push > around people. When you speak about an "immature SW", do you speak about Koji or Bodhi? Koji is deployed, and the dev is here. Bodhi is not deployed yet. IMO, you are loosing everbody's time, in the current thread. Please fill bugs about any bug you may see, and advertise them once in this thread. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From j.w.r.degoede at hhs.nl Mon May 21 22:03:47 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 22 May 2007 00:03:47 +0200 Subject: FC/FE-6 plague builds screwed up ?? Message-ID: <46521743.3080005@hhs.nl> Hi all, Very strange this, from: http://buildsys.fedoraproject.org/logs/fedora-6-extras/33528-ants-1.4-2.fc6/i386/root.log ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: allegro-devel i386 4.2.0-18.fc6 extras 2.5 M desktop-file-utils i386 0.10-7 core 59 k Installing for dependencies: allegro i386 4.2.0-18.fc6 extras 624 k alsa-lib i386 1.0.14-0.1.rc1.fc6 updates-released 408 k arts i386 8:1.5.6-0.1.fc6 updates-released 1.1 M audiofile i386 1:0.2.6-5 core 107 k esound i386 1:0.2.36-3 core 130 k fontconfig i386 2.4.1-3.fc6 core 175 k freetype i386 2.2.1-16.fc6 updates-released 312 k lcms i386 1.15-1.2.2 core 168 k libICE i386 1.0.1-2.1 core 53 k libSM i386 1.0.1-3.1 core 27 k libX11 i386 1.0.3-7.fc6 updates-released 794 k libX11-devel i386 1.0.3-7.fc6 updates-released 665 k libXau i386 1.0.1-3.1 core 18 k libXau-devel i386 1.0.1-3.1 core 11 k libXaw i386 1.0.2-8.1 core 325 k libXcursor i386 1.1.7-1.1 core 32 k libXcursor-devel i386 1.1.7-1.1 core 14 k libXdmcp i386 1.0.1-2.1 core 19 k libXdmcp-devel i386 1.0.1-2.1 core 7.6 k libXfixes i386 4.0.1-2.1 core 14 k libXft i386 2.1.10-1.1 core 44 k libXinerama i386 1.0.1-2.1 core 9.9 k libXmu i386 1.0.2-5 core 63 k libXpm i386 3.5.5-3 core 45 k libXrandr i386 1.1.1-3.1 core 15 k libXt i386 1.0.2-3.1.fc6 core 174 k libXxf86dga i386 1.0.1-3.1 core 15 k libXxf86vm i386 1.0.1-3.1 core 14 k libdrm i386 2.3.0-1.fc6 updates-released 24 k libjpeg i386 6b-37 core 139 k libmng i386 1.0.9-5.1 core 167 k libogg i386 2:1.1.3-2.fc6 core 19 k libpng i386 2:1.2.10-7 core 242 k libtiff i386 3.8.2-6.fc6 core 312 k libvorbis i386 1:1.1.2-1.2.1 core 192 k mesa-libGL i386 6.5.1-9.fc6 updates-released 9.7 M mesa-libGL-devel i386 6.5.1-9.fc6 updates-released 464 k nx i386 2.1.0-19.fc6 extras 3.7 M pkgconfig i386 1:0.21-1.fc6 core 58 k qt i386 1:3.3.7-0.1.fc6 updates-released 3.6 M timidity++ i386 2.13.2-1.2.2 core 9.0 M xorg-x11-filesystem noarch 7.1-2.fc6 core 5.5 k xorg-x11-proto-devel i386 7.1-9.fc6 core 247 k Notice how libXext isn't getting installed even though allegro requires libXext.so.6 (I just checked the FC-6 package for this to be sure) ???? Regards, Hans From j.w.r.degoede at hhs.nl Mon May 21 22:09:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 22 May 2007 00:09:01 +0200 Subject: Fedora Package Status of May 21, 2007 In-Reply-To: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> References: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> Message-ID: <4652187D.8050209@hhs.nl> Christian Iseli wrote: > The full report can be found here: > http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus > This page seems to not have been updated. Regards, Hans From bugs.michael at gmx.net Mon May 21 21:57:57 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Mon, 21 May 2007 23:57:57 +0200 Subject: FC/FE-6 plague builds screwed up ?? In-Reply-To: <46521743.3080005@hhs.nl> References: <46521743.3080005@hhs.nl> Message-ID: <20070521235757.c265f2ec.bugs.michael@gmx.net> On Tue, 22 May 2007 00:03:47 +0200, Hans de Goede wrote: > Hi all, > > Very strange this, from: > http://buildsys.fedoraproject.org/logs/fedora-6-extras/33528-ants-1.4-2.fc6/i386/root.log > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Installing: > allegro-devel i386 4.2.0-18.fc6 extras 2.5 M > desktop-file-utils i386 0.10-7 core 59 k > Installing for dependencies: > allegro i386 4.2.0-18.fc6 extras 624 k > alsa-lib i386 1.0.14-0.1.rc1.fc6 updates-released 408 k > arts i386 8:1.5.6-0.1.fc6 updates-released 1.1 M > audiofile i386 1:0.2.6-5 core 107 k > esound i386 1:0.2.36-3 core 130 k > fontconfig i386 2.4.1-3.fc6 core 175 k > freetype i386 2.2.1-16.fc6 updates-released 312 k > lcms i386 1.15-1.2.2 core 168 k > libICE i386 1.0.1-2.1 core 53 k > libSM i386 1.0.1-3.1 core 27 k > libX11 i386 1.0.3-7.fc6 updates-released 794 k > libX11-devel i386 1.0.3-7.fc6 updates-released 665 k > libXau i386 1.0.1-3.1 core 18 k > libXau-devel i386 1.0.1-3.1 core 11 k > libXaw i386 1.0.2-8.1 core 325 k > libXcursor i386 1.1.7-1.1 core 32 k > libXcursor-devel i386 1.1.7-1.1 core 14 k > libXdmcp i386 1.0.1-2.1 core 19 k > libXdmcp-devel i386 1.0.1-2.1 core 7.6 k > libXfixes i386 4.0.1-2.1 core 14 k > libXft i386 2.1.10-1.1 core 44 k > libXinerama i386 1.0.1-2.1 core 9.9 k > libXmu i386 1.0.2-5 core 63 k > libXpm i386 3.5.5-3 core 45 k > libXrandr i386 1.1.1-3.1 core 15 k > libXt i386 1.0.2-3.1.fc6 core 174 k > libXxf86dga i386 1.0.1-3.1 core 15 k > libXxf86vm i386 1.0.1-3.1 core 14 k > libdrm i386 2.3.0-1.fc6 updates-released 24 k > libjpeg i386 6b-37 core 139 k > libmng i386 1.0.9-5.1 core 167 k > libogg i386 2:1.1.3-2.fc6 core 19 k > libpng i386 2:1.2.10-7 core 242 k > libtiff i386 3.8.2-6.fc6 core 312 k > libvorbis i386 1:1.1.2-1.2.1 core 192 k > mesa-libGL i386 6.5.1-9.fc6 updates-released 9.7 M > mesa-libGL-devel i386 6.5.1-9.fc6 updates-released 464 k > nx i386 2.1.0-19.fc6 extras 3.7 M > pkgconfig i386 1:0.21-1.fc6 core 58 k > qt i386 1:3.3.7-0.1.fc6 updates-released 3.6 M > timidity++ i386 2.13.2-1.2.2 core 9.0 M > xorg-x11-filesystem noarch 7.1-2.fc6 core 5.5 k > xorg-x11-proto-devel i386 7.1-9.fc6 core 247 k > > Notice how libXext isn't getting installed even though allegro requires > libXext.so.6 (I just checked the FC-6 package for this to be sure) > > ???? Blame the "nx" packager. I'm going to pull the nx/freenx updates as this is an emergency. Objections, anyone? I will keep them in needsign, blacklisted. From j.w.r.degoede at hhs.nl Mon May 21 22:21:48 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 22 May 2007 00:21:48 +0200 Subject: FC/FE-6 plague builds screwed up ?? In-Reply-To: <20070521235757.c265f2ec.bugs.michael@gmx.net> References: <46521743.3080005@hhs.nl> <20070521235757.c265f2ec.bugs.michael@gmx.net> Message-ID: <46521B7C.8040004@hhs.nl> Michael Schwendt wrote: > On Tue, 22 May 2007 00:03:47 +0200, Hans de Goede wrote: > >> Hi all, >> >> Very strange this, from: >> http://buildsys.fedoraproject.org/logs/fedora-6-extras/33528-ants-1.4-2.fc6/i386/root.log >> >> ============================================================================= >> Package Arch Version Repository Size >> ============================================================================= >> Installing: >> allegro-devel i386 4.2.0-18.fc6 extras 2.5 M >> desktop-file-utils i386 0.10-7 core 59 k >> Installing for dependencies: >> allegro i386 4.2.0-18.fc6 extras 624 k >> alsa-lib i386 1.0.14-0.1.rc1.fc6 updates-released 408 k >> arts i386 8:1.5.6-0.1.fc6 updates-released 1.1 M >> audiofile i386 1:0.2.6-5 core 107 k >> esound i386 1:0.2.36-3 core 130 k >> fontconfig i386 2.4.1-3.fc6 core 175 k >> freetype i386 2.2.1-16.fc6 updates-released 312 k >> lcms i386 1.15-1.2.2 core 168 k >> libICE i386 1.0.1-2.1 core 53 k >> libSM i386 1.0.1-3.1 core 27 k >> libX11 i386 1.0.3-7.fc6 updates-released 794 k >> libX11-devel i386 1.0.3-7.fc6 updates-released 665 k >> libXau i386 1.0.1-3.1 core 18 k >> libXau-devel i386 1.0.1-3.1 core 11 k >> libXaw i386 1.0.2-8.1 core 325 k >> libXcursor i386 1.1.7-1.1 core 32 k >> libXcursor-devel i386 1.1.7-1.1 core 14 k >> libXdmcp i386 1.0.1-2.1 core 19 k >> libXdmcp-devel i386 1.0.1-2.1 core 7.6 k >> libXfixes i386 4.0.1-2.1 core 14 k >> libXft i386 2.1.10-1.1 core 44 k >> libXinerama i386 1.0.1-2.1 core 9.9 k >> libXmu i386 1.0.2-5 core 63 k >> libXpm i386 3.5.5-3 core 45 k >> libXrandr i386 1.1.1-3.1 core 15 k >> libXt i386 1.0.2-3.1.fc6 core 174 k >> libXxf86dga i386 1.0.1-3.1 core 15 k >> libXxf86vm i386 1.0.1-3.1 core 14 k >> libdrm i386 2.3.0-1.fc6 updates-released 24 k >> libjpeg i386 6b-37 core 139 k >> libmng i386 1.0.9-5.1 core 167 k >> libogg i386 2:1.1.3-2.fc6 core 19 k >> libpng i386 2:1.2.10-7 core 242 k >> libtiff i386 3.8.2-6.fc6 core 312 k >> libvorbis i386 1:1.1.2-1.2.1 core 192 k >> mesa-libGL i386 6.5.1-9.fc6 updates-released 9.7 M >> mesa-libGL-devel i386 6.5.1-9.fc6 updates-released 464 k >> nx i386 2.1.0-19.fc6 extras 3.7 M >> pkgconfig i386 1:0.21-1.fc6 core 58 k >> qt i386 1:3.3.7-0.1.fc6 updates-released 3.6 M >> timidity++ i386 2.13.2-1.2.2 core 9.0 M >> xorg-x11-filesystem noarch 7.1-2.fc6 core 5.5 k >> xorg-x11-proto-devel i386 7.1-9.fc6 core 247 k >> >> Notice how libXext isn't getting installed even though allegro requires >> libXext.so.6 (I just checked the FC-6 package for this to be sure) >> >> ???? > > Blame the "nx" packager. I'm going to pull the nx/freenx updates > as this is an emergency. > > Objections, anyone? I will keep them in needsign, blacklisted. > Wouldn't keeping them in needsign still make them available to plague, as plague build against needsign packages too, or am I missing something? Otherwise this gets a +1 from me. Regards, Hans From mr.ecik at gmail.com Mon May 21 22:10:32 2007 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 22 May 2007 00:10:32 +0200 Subject: Fedora Package Status of May 21, 2007 In-Reply-To: <4652187D.8050209@hhs.nl> References: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> <4652187D.8050209@hhs.nl> Message-ID: <668bb39a0705211510h4a14daa4v120284ff25f43575@mail.gmail.com> 2007/5/22, Hans de Goede : > This page seems to not have been updated. Read carefully: > I attempted to put the report on the wiki, but so far failed... so if > anyone closer to the beast could upload the attached text in the page, > that would be cool :-) -- Micha? Bentkowski mr.ecik at gmail.com From Christian.Iseli at licr.org Mon May 21 22:29:29 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 22 May 2007 00:29:29 +0200 Subject: Fedora Package Status of May 21, 2007 In-Reply-To: References: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> Message-ID: <20070522002929.7e3a3378@ludwig-alpha.unil.ch> On Mon, 21 May 2007 13:19:02 -0700, Christopher Stone wrote: > FYI, the Top 30 BZ review requests reviewers section does not seem to > be picking up my latest reviews like bug #227241 or #238367 The wiki page wasn't updated yet. They are there now. Cheers, C From Christian.Iseli at licr.org Mon May 21 22:30:53 2007 From: Christian.Iseli at licr.org (Christian Iseli) Date: Tue, 22 May 2007 00:30:53 +0200 Subject: Fedora Package Status of May 21, 2007 In-Reply-To: <4652187D.8050209@hhs.nl> References: <20070521190553.5e93e9f0@ludwig-alpha.unil.ch> <4652187D.8050209@hhs.nl> Message-ID: <20070522003053.4d7935c0@ludwig-alpha.unil.ch> On Tue, 22 May 2007 00:09:01 +0200, Hans de Goede wrote: > This page seems to not have been updated. Yea, I failed several times (some sort of proxy timeout which I forgot to copy down, cause I did it in a hurry...) It should be all there now. Cheers, C From bugs.michael at gmx.net Mon May 21 22:20:30 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 22 May 2007 00:20:30 +0200 Subject: FC/FE-6 plague builds screwed up ?? In-Reply-To: <46521B7C.8040004@hhs.nl> References: <46521743.3080005@hhs.nl> <20070521235757.c265f2ec.bugs.michael@gmx.net> <46521B7C.8040004@hhs.nl> Message-ID: <20070522002030.e50766bf.bugs.michael@gmx.net> On Tue, 22 May 2007 00:21:48 +0200, Hans de Goede wrote: > >> Very strange this, from: > >> http://buildsys.fedoraproject.org/logs/fedora-6-extras/33528-ants-1.4-2.fc6/i386/root.log > >> Notice how libXext isn't getting installed even though allegro requires > >> libXext.so.6 (I just checked the FC-6 package for this to be sure) > >> > >> ???? > > > > Blame the "nx" packager. I'm going to pull the nx/freenx updates > > as this is an emergency. > > > > Objections, anyone? I will keep them in needsign, blacklisted. > > > > Wouldn't keeping them in needsign still make them available to plague, as > plague build against needsign packages too, or am I missing something? > > Otherwise this gets a +1 from me. Yeah, small oversight. You're right, of course. Anyway, I've moved away the nx/freenx update in FE6 and FE5 and needsign, and as soon as the master mirror is synced, they should not reappear in the buildroots. From nicolas.mailhot at laposte.net Mon May 21 23:14:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 22 May 2007 01:14:04 +0200 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <20070521210906.GJ2486@nostromo.devel.redhat.com> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> <20070519163244.4cd70e5b.bugs.michael@gmx.net> <1179760611.18583.29.camel@localhost.localdomain> <20070521210906.GJ2486@nostromo.devel.redhat.com> Message-ID: <1179789244.23187.1.camel@rousalka.dyndns.org> Le lundi 21 mai 2007 ? 17:09 -0400, Bill Nottingham a ?crit : > > Is anyone reporting these as "things we shouldn't have to care about" to > > rpm-maint@ or the appropriate bugzilla? > > It's somewhat tricky to fix - you're asking rpm-the-parser to either > a) elide anything that starts with '#' from all scriplets, even though > it may be valid in some interpreter > b) conditionally elide it based on what the scriplet interpreter c) barf at rpmbuild time on non-shell scriptlets containing # lines -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Tue May 22 00:22:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 May 2007 20:22:56 -0400 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <1179789244.23187.1.camel@rousalka.dyndns.org> References: <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> <20070519163244.4cd70e5b.bugs.michael@gmx.net> <1179760611.18583.29.camel@localhost.localdomain> <20070521210906.GJ2486@nostromo.devel.redhat.com> <1179789244.23187.1.camel@rousalka.dyndns.org> Message-ID: <20070522002256.GE5509@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > It's somewhat tricky to fix - you're asking rpm-the-parser to either > > a) elide anything that starts with '#' from all scriplets, even though > > it may be valid in some interpreter > > b) conditionally elide it based on what the scriplet interpreter > > c) barf at rpmbuild time on non-shell scriptlets containing # lines Sure, it's still adding parsing of the scriplets themselves to the parser. And I'm sure someone will come up with a valid use for such a line with %post -p /usr/bin/perl or somesuch. Bill From bpepple at fedoraproject.org Tue May 22 00:47:03 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 21 May 2007 20:47:03 -0400 Subject: FESCo Meeting Summary for 2007-05-17 Message-ID: <1179794823.5752.4.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) * Warren Togami (warren) * Jeremy Katz (jeremy) * Tom Callaway (spot) * Rex Dieter (rdieter) === Members Absent === * Christian Iseli (c4chris) == Summary == === Package DB === * It's expected that the Package DB should go into production shortly after F7 is released. === Enforcement of Packaging Guidelines === * Long discussion on how to handle enforcement of packaging guidelines when a package maintainer refuses to follow them. Peter Jones wrote a proposal which FESCo will vote on next week. https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00634.html === Compat Package policy === * jeremy is working on his proposal, and will look at completing it after F7 is out-the-door. http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages === Misc ==== * tibbs is going to send an e-mail to mailing lists regarding packages that download non-redistributable content, to get feedback from the community. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070517 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Tue May 22 02:57:43 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 22 May 2007 11:57:43 +0900 Subject: plague buildsys seems in disk shortage In-Reply-To: <20070521211734.9de4601e.bugs.michael@gmx.net> References: <4651E5BE.1070604@ioa.s.u-tokyo.ac.jp> <20070521211734.9de4601e.bugs.michael@gmx.net> Message-ID: <46525C27.8070900@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote, at 05/22/2007 04:17 AM +9:00: > On Tue, 22 May 2007 03:32:30 +0900, Mamoru Tasaka wrote: > >> Hello. >> >> I submitted 4 build queues of my packages to plague >> buildsys, however all of them failed due to >> disk shortage (perhaps). >> Thank you in advance. > > Please requeue. Thank you, Michael and Mike. I requeued all my jobs which previously failed and this time they succeeded. Mamoru From a.badger at gmail.com Tue May 22 02:58:55 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 May 2007 19:58:55 -0700 Subject: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070520224451.GB11171@free.fr> References: <200705151259.51792.jkeating@redhat.com> <20070515191507.cfeb4274.bugs.michael@gmx.net> <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <1179362111.2746.311.camel@localhost.localdomain> <20070520224451.GB11171@free.fr> Message-ID: <1179802735.5161.60.camel@localhost.localdomain> On Mon, 2007-05-21 at 00:44 +0200, Patrice Dumas wrote: > On Wed, May 16, 2007 at 05:35:11PM -0700, Toshio Kuratomi wrote: > > The static-libs naming was resolved on list with no guidelines changes > > needing to be made. > > I was not referring to the static-libs naming itself but to the > following discussion, starting approximately at > > https://www.redhat.com/archives/fedora-packaging/2007-April/msg00185.html > > > The static library thread basically came to the same place that we are > > at here. You have to follow the Guidelines. The reasons that the > > guidelines are written as they are is in Ralf's email and in this > > current exchange. By following the Guidelines you can help get them to > > change. > > I can't see how. I can lose a lot of time I could devote to other tasks, > however. > As I said, that thread contains two pieces -- naming (which had a solution) and libraries which should have static libs. I don't see anything in that thread that can be used to formulate a guideline of when a static library should be allowed in general. Please point us to the thread which gives the criteria that we can use to determine if a library is part of the category that should be allowed to ship static libraries. > > Express an example of silliness and present a draft with the example as > > something that should be allowed. However, the attitude that there are > > some changes that are too silly to be recorded in the changelog is > > exactly why the people that voted for the changelog guideline voted for > > it. You are violating the spirit of the guideline as well as the letter > > by not putting a changelog entry in and I think your draft, example, and > > arguments will have to be very persuasive in order to make a change to > > this guideline. > > Honestly for this example I thought I wasn't really violating the > guideline and it was implicitly ok to avoid some changelog entries as > the reverse seems so unnatural and bureaucratic to me. Moreover I have > seen a lot of other packagers doing that while reading the commit > messages without anybody complaining, so I thought it was ok, I stand > corrected. > We could be talking about different things... it's hard to tell from looking at your changelog :-) Every build must have a new changelog entry. Every commit does not. So when I see this changelog: * Mon May 14 2007 Patrice Dumas 2006-10.1 - packlib/{ffread,hbook} test segfaults on ppc64 * Sun May 13 2007 Patrice Dumas 2006-9 - add a compat prefix when built with g77 - new debian patcheset It's fine if 2006-10 was never built. You should have had another entry if 2006-10 was committed but not built. > > Not true. A Makefile can do whatever it wants. A spec file is also > > just a shell script when it comes down to it. > > Of course it can. But if there is a package not using -l to link it is a > serious bug already. And having static libs in -static subpackages means > that it really cannot happen, this point is moot. > Not quite. If you have a package which provides libraries and utilities it can very easily be linking against static versions of the library instead of the dynamic versions without pulling in a -static subpackage. > > > I did it without success. > > No. You did it without succeeding in getting the guidelines changed. > > You have a minority opinion. So you have to do some legwork to get the > > majority to come over to your viewpoint. The most effective way to do > > that in this case is not to write arguments to the mailing list. The > > most effective way is to follow the guidelines and thereby amass a body > > of packaging that supports your statements and shows what changes need > > to be written into the guidelines. > > I don't have time, nor will to do that kind of work. I have arguments > nobody responds to, I don't need to give number or evidences. > You have arguments that other people feel are made moot because of the arguments they have already stated. That is why they don't respond. You have to present all your arguments so we can see if those people are right or if there are still some arguments left on your side that are unaddressed. > > You claim that the guidelines should be changed to allow numerical > > libraries to ship static libs but I can honestly say that FESCo has not > > been asked to allow one numerical library to ship a static library since > > the guideline went into effect. By bypassing the guidelines you're > > making it so we are unaware of the problems with the guidelines and > > denying us the data to change the guidelines to be better. > > I have always said, and I'll say it once more that I was ready to give > the data, not to ask for permission. > But you have failed to even do that. Phrase your letter as data if you like and just shrug your shoulders if you receive a letter back saying "Approved". > > Once that's done, write another letter that says "These libraries have > > no shared libraries upstream. Thus they need to ship static libraries." > > and repeat. > > Are you really meaning that the guideline (that is asking FESCo for > static libs inclusion) is also in order for packages that ship only > static libs. Once again it seems so weird to me that I figured that it > wasn't needed. > It's one way to read the guidelines, yes. I think that needs to change: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges [snip] Since you're unwilling to do any of the work to get the guidelines changed, here's what I'm going to be working on: The guidelines currently lump inclusion of static libraries and linking to static libraries in the same guideline. I'll be proposing a revision that separates those two. Inclusion of static libraries is up to the maintainer as long as the requirement to put static libraries in a -static package is met. Rework the -static subpackage requirement to take into account Ralf's message about -static/-devel packages in the absence of a dynamic library. I'm not going to ask to change the guidelines WRT linking to static libraries. (You'll still have to ask FESCo if you want to link to a static libary). I'm not going to ask for a special case exception for numerical libraries. These are significant changes from the current guidelines and they might not be approved by the Packaging Committee in which case your packaging will still be out of compliance and someone could open bugs against your packages. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Tue May 22 04:39:24 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 22 May 2007 00:39:24 -0400 Subject: [PATCH] Update to branches system to match recent DistTag change Message-ID: <1179808764.3109.13.camel@ignacio.lan> This patch makes the branches system in cvs define the same tag as the buildsys-macros package now does. It also cleans out a bit of cruft that could cause a rpm command line to be too long. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: dist-fix.patch Type: text/x-patch Size: 1582 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 fedora at leemhuis.info Tue May 22 05:10:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 22 May 2007 07:10:04 +0200 Subject: Build problem for EPEL-4 In-Reply-To: <1179780032.8858.24.camel@bureau.maison> References: <1179772672.8858.21.camel@bureau.maison> <1179780032.8858.24.camel@bureau.maison> Message-ID: <46527B2C.2080800@leemhuis.info> On 21.05.2007 22:40, Tanguy Eric wrote: > Le lundi 21 mai 2007 ? 20:37 +0200, Tanguy Eric a ?crit : >> I tried to build some packages for EL-4 and all fail due to the same >> error : >> http://buildsys.fedoraproject.org/logs/fedora-4-epel/33515-ushare-0.9.7-2.el4/ppc/root.log >> > Someone could help me to understand why i have this building error with > plague or epel4 : > Executing /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-4-ppc-epel-a343a52ceeb20dafb214d3b08f12dfa5dbc09a17/root install buildsys-build > http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Mon, 21 May 2007 20:37:12 GMT > Server: Apache/2.0.52 > Content-Length: 342 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > Trying other mirror. > Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] No more mirrors to try. > Cleaning up... > > The problem come from me or the system ? No, doesn't look like it. >From a *quick* look is seems to me like rpmdevtools was pushed to the repo and deleted from the needsign repo without the needsign repodata being regenerated. Seems someone rebuild that metadata in the past hours. Try again. CU thl From bugs.michael at gmx.net Tue May 22 07:44:14 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 22 May 2007 09:44:14 +0200 Subject: Build problem for EPEL-4 In-Reply-To: <46527B2C.2080800@leemhuis.info> References: <1179772672.8858.21.camel@bureau.maison> <1179780032.8858.24.camel@bureau.maison> <46527B2C.2080800@leemhuis.info> Message-ID: <20070522094414.6177b455.bugs.michael@gmx.net> On Tue, 22 May 2007 07:10:04 +0200, Thorsten Leemhuis wrote: > On 21.05.2007 22:40, Tanguy Eric wrote: > > Le lundi 21 mai 2007 ? 20:37 +0200, Tanguy Eric a ?crit : > >> I tried to build some packages for EL-4 and all fail due to the same > >> error : > >> http://buildsys.fedoraproject.org/logs/fedora-4-epel/33515-ushare-0.9.7-2.el4/ppc/root.log > >> > > Someone could help me to understand why i have this building error with > > plague or epel4 : > > Executing /usr/sbin/mock-helper yum > > --installroot /var/lib/mock/fedora-4-ppc-epel-a343a52ceeb20dafb214d3b08f12dfa5dbc09a17/root install buildsys-build > > http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Mon, 21 May 2007 20:37:12 GMT > > Server: Apache/2.0.52 > > Content-Length: 342 > > Connection: close > > Content-Type: text/html; charset=iso-8859-1 > > > > Trying other mirror. > > Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] No more mirrors to try. > > Cleaning up... > > > > The problem come from me or the system ? > > No, doesn't look like it. > > >>From a *quick* look is seems to me like rpmdevtools was pushed to the > repo and deleted from the needsign repo without the needsign repodata > being regenerated. > > Seems someone rebuild that metadata in the past hours. Try again. Where do you see this? Unfortunately, above logs have not been preserved, but have been overwritten with a successful rebuild. While rpmdevtools-5.3-1.el4.noarch.rpm is in the EPEL4 repo since early March, I see no -1.fc5 release in the repo and not in needsign and not in build reports and not in plague-web either. Further, the following is not a valid plague-results path: http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404 If at all, this package was copied to this place temporarily and manually by somebody without updating the metadata after removing it again. -- Michael Schwendt Fedora Core release 6 (Zod) - Linux 2.6.20-1.2948.fc6 loadavg: 1.15 1.37 1.06 From fedora at leemhuis.info Tue May 22 08:17:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 22 May 2007 10:17:16 +0200 Subject: Build problem for EPEL-4 In-Reply-To: <20070522094414.6177b455.bugs.michael@gmx.net> References: <1179772672.8858.21.camel@bureau.maison> <1179780032.8858.24.camel@bureau.maison> <46527B2C.2080800@leemhuis.info> <20070522094414.6177b455.bugs.michael@gmx.net> Message-ID: <4652A70C.8020602@leemhuis.info> On 22.05.2007 09:44, Michael Schwendt wrote: > On Tue, 22 May 2007 07:10:04 +0200, Thorsten Leemhuis wrote: >> On 21.05.2007 22:40, Tanguy Eric wrote: >>> Le lundi 21 mai 2007 ? 20:37 +0200, Tanguy Eric a ?crit : >>>> I tried to build some packages for EL-4 and all fail due to the same >>>> error : >>>> http://buildsys.fedoraproject.org/logs/fedora-4-epel/33515-ushare-0.9.7-2.el4/ppc/root.log >>>> >>> Someone could help me to understand why i have this building error with >>> plague or epel4 : >>> Executing /usr/sbin/mock-helper yum >>> --installroot /var/lib/mock/fedora-4-ppc-epel-a343a52ceeb20dafb214d3b08f12dfa5dbc09a17/root install buildsys-build >>> http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404: Date: Mon, 21 May 2007 20:37:12 GMT >>> Server: Apache/2.0.52 >>> Content-Length: 342 >>> Connection: close >>> Content-Type: text/html; charset=iso-8859-1 >>> Trying other mirror. >>> Error: failure: rpmdevtools-5.3-1.fc5.noarch.rpm from local: [Errno 256] No more mirrors to try. >>> Cleaning up... >>> The problem come from me or the system ? >> No, doesn't look like it. >>> >From a *quick* look is seems to me like rpmdevtools was pushed to the >> repo and deleted from the needsign repo without the needsign repodata >> being regenerated. >> Seems someone rebuild that metadata in the past hours. Try again. > Where do you see this? When I looked this morning I noticed the metadata for the needsign repo was freshly generated and didn't contain any informations about packages -- dgilmore told me he regenerated it. And in between there were some builds again. > Unfortunately, above logs have not been preserved, but have been > overwritten with a successful rebuild. > > While rpmdevtools-5.3-1.el4.noarch.rpm is in the EPEL4 repo since early > March, I see no -1.fc5 release in the repo and not in needsign and > not in build reports and not in plague-web either. Yeah, your correct, so my conclusions from my "quick look" were wrong. :-/ > Further, the following is not a valid plague-results path: > http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/rpmdevtools-5.3-1.fc5.noarch.rpm: [Errno 14] HTTP Error 404 > > If at all, this package was copied to this place temporarily and manually > by somebody without updating the metadata after removing it again. Yeah, something like that maybe. CU thl From jonathan.underwood at gmail.com Tue May 22 09:42:08 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 22 May 2007 10:42:08 +0100 Subject: Koji suggestion: making build logs much more accessible. Message-ID: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> Hi, I noticed something I think is a bit of a feature regression with koji compared to plague. I maintain the sunifdef package, and as part of my communication with the upstream developer I often pointed him the the location of build logs for each package update. The upstream developer has in the past found this valuable as he doesn't have access to as many platforms for testing as the Fedora build farm has. Since the package contains a test suite, building packages for fedora actually serves as a really useful test for regressions across platforms. Now, with plague, I'd recieve an email with a single URL to point the developer to for buildlogs across all platforms. With Koji I get a massively long email with lots of very useful detail. But In order to point the developer to build logs, I have to send a heap of URLs (or just forward the email). Would it be possible to rationalize all this a bit to provide a single URL and a sensible archiving hierarchy for the logs? Cheers, Jonathan. From Axel.Thimm at ATrpms.net Tue May 22 10:04:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 May 2007 12:04:18 +0200 Subject: koji: make build non-interactive? Message-ID: <20070522100418.GC26847@neu.nirvana> Hi, how can I call a make build w/o having to watch the build progress? I don't want to use Ctrl-C, I'd like to be able to script around make build. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue May 22 10:13:49 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 May 2007 12:13:49 +0200 Subject: splitting a package into many (src.rpm wise): resubmit or special handling? Message-ID: <20070522101349.GD26847@neu.nirvana> This is about nx which is a conglomeration of several (8) different source tarballs. This is a historical design which has some drawbacks like having to rebuild all 8 "subpackages" when only one changes. Now, technically splitting the (source) package into 8 (source) packages is less the problem, I'm more afraid of having to submit all 8 pieces and wait for reviews of each one of them. Any chance this could be special handled by a cvsadmin? Does fesco or some other instance need to approve? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From laroche at redhat.com Tue May 22 10:16:19 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 22 May 2007 12:16:19 +0200 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <20070522002256.GE5509@nostromo.devel.redhat.com> References: <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> <20070519163244.4cd70e5b.bugs.michael@gmx.net> <1179760611.18583.29.camel@localhost.localdomain> <20070521210906.GJ2486@nostromo.devel.redhat.com> <1179789244.23187.1.camel@rousalka.dyndns.org> <20070522002256.GE5509@nostromo.devel.redhat.com> Message-ID: <20070522101619.GC3637@dudweiler.stuttgart.redhat.com> On Mon, May 21, 2007 at 08:22:56PM -0400, Bill Nottingham wrote: > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > > It's somewhat tricky to fix - you're asking rpm-the-parser to either > > > a) elide anything that starts with '#' from all scriplets, even though > > > it may be valid in some interpreter > > > b) conditionally elide it based on what the scriplet interpreter > > > > c) barf at rpmbuild time on non-shell scriptlets containing # lines > > Sure, it's still adding parsing of the scriplets themselves to the parser. > And I'm sure someone will come up with a valid use for such a line with > %post -p /usr/bin/perl or somesuch. This should be only a warning and then you can argue if this should be in rpm or in rpmlint. regards, Florian La Roche From fedora at leemhuis.info Tue May 22 10:18:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 22 May 2007 12:18:33 +0200 Subject: koji: make build non-interactive? In-Reply-To: <20070522100418.GC26847@neu.nirvana> References: <20070522100418.GC26847@neu.nirvana> Message-ID: <4652C379.10708@leemhuis.info> Hi! On 22.05.2007 12:04, Axel Thimm wrote: > how can I call a make build w/o having to watch the build progress? I > don't want to use Ctrl-C, I'd like to be able to script around make > build. https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00089.html Quoting: >> Is there a way to cause koji to return once the job is queued? > > KOJI_FLAGS="--nowait" or I do believe you can set something in .kojirc like > this. There is also some stuff on http://fedoraproject.org/wiki/Koji/UsingKoji Hope this helps. CU thl From dev at nigelj.com Tue May 22 11:42:26 2007 From: dev at nigelj.com (Nigel Jones) Date: Tue, 22 May 2007 23:42:26 +1200 Subject: splitting a package into many (src.rpm wise): resubmit or special handling? In-Reply-To: <20070522101349.GD26847@neu.nirvana> References: <20070522101349.GD26847@neu.nirvana> Message-ID: <4652D722.5040500@nigelj.com> Axel Thimm wrote: > This is about nx which is a conglomeration of several (8) different > source tarballs. This is a historical design which has some drawbacks > like having to rebuild all 8 "subpackages" when only one changes. > > Now, technically splitting the (source) package into 8 (source) > packages is less the problem, I'm more afraid of having to submit all > 8 pieces and wait for reviews of each one of them. Any chance this > could be special handled by a cvsadmin? Does fesco or some other > instance need to approve? For something like this, how I'd like to see it handled, is one master review bug#, with the 8 specfiles, and label the review as 'Review Request: nx-* - Package split'. N.J. From jonathan.underwood at gmail.com Tue May 22 11:49:21 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 22 May 2007 12:49:21 +0100 Subject: splitting a package into many (src.rpm wise): resubmit or special handling? In-Reply-To: <4652D722.5040500@nigelj.com> References: <20070522101349.GD26847@neu.nirvana> <4652D722.5040500@nigelj.com> Message-ID: <645d17210705220449o27ec1942iac6c82a79b9114fe@mail.gmail.com> On 22/05/07, Nigel Jones wrote: > For something like this, how I'd like to see it handled, is one master > review bug#, with the 8 specfiles, and label the review as 'Review > Request: nx-* - Package split'. Sure, but Axel was asking whether or not he'd have to wait for such a review to finish before pushing the packages. Personally I think this instance should be treated like a Merge Review - i.e. the review doesn't block Axel pushing new packages. Jonathan From Axel.Thimm at ATrpms.net Tue May 22 11:50:51 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 May 2007 13:50:51 +0200 Subject: splitting a package into many (src.rpm wise): resubmit or special handling? In-Reply-To: <4652D722.5040500@nigelj.com> References: <20070522101349.GD26847@neu.nirvana> <4652D722.5040500@nigelj.com> Message-ID: <20070522115051.GF26847@neu.nirvana> On Tue, May 22, 2007 at 11:42:26PM +1200, Nigel Jones wrote: > Axel Thimm wrote: > > This is about nx which is a conglomeration of several (8) different > > source tarballs. This is a historical design which has some drawbacks > > like having to rebuild all 8 "subpackages" when only one changes. > > > > Now, technically splitting the (source) package into 8 (source) > > packages is less the problem, I'm more afraid of having to submit all > > 8 pieces and wait for reviews of each one of them. Any chance this > > could be special handled by a cvsadmin? Does fesco or some other > > instance need to approve? > For something like this, how I'd like to see it handled, is one master > review bug#, with the 8 specfiles, and label the review as 'Review > Request: nx-* - Package split'. Well, the idea is not to stall the package with any review request. My packages have a typical review turn around of several months to a year. Semantically it isn't much different from deciding to change subpackage structure and noone would require ever packager to resubmit his package for adding/changing a subpackage. Only this time the split is already at the source level and involves cvs/bugzilla etc. high level changes. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Tue May 22 11:52:08 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 22 May 2007 12:52:08 +0100 Subject: koji: make build non-interactive? In-Reply-To: <4652C379.10708@leemhuis.info> References: <20070522100418.GC26847@neu.nirvana> <4652C379.10708@leemhuis.info> Message-ID: <645d17210705220452y84d12d5u6777cf58771e72d8@mail.gmail.com> On 22/05/07, Thorsten Leemhuis wrote: > > There is also some stuff on > http://fedoraproject.org/wiki/Koji/UsingKoji Groan. Yet again, documentation hidden from view. Why is there no mention of this documentation at http://fedoraproject.org/wiki/PackageMaintainers That's the first place I go to look for information when, as a packager, I am unsure about something. I'll add a link now, but really would like to encourage people to not hide documentation away! Jonathan. From fedora at leemhuis.info Tue May 22 12:00:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 22 May 2007 14:00:40 +0200 Subject: koji: make build non-interactive? In-Reply-To: <645d17210705220452y84d12d5u6777cf58771e72d8@mail.gmail.com> References: <20070522100418.GC26847@neu.nirvana> <4652C379.10708@leemhuis.info> <645d17210705220452y84d12d5u6777cf58771e72d8@mail.gmail.com> Message-ID: <4652DB68.1050103@leemhuis.info> On 22.05.2007 13:52, Jonathan Underwood wrote: > On 22/05/07, Thorsten Leemhuis wrote: >> There is also some stuff on >> http://fedoraproject.org/wiki/Koji/UsingKoji > > Groan. > Yet again, documentation hidden from view. > Why is there no mention of this documentation at /me found it accidentally with google ;-) > http://fedoraproject.org/wiki/PackageMaintainers > That's the first place I go to look for information when, as a > packager, I am unsure about something. > I'll add a link now, but really would like to encourage people to not > hide documentation away! My 2 cent: for this and other problems we faced with the wiki docs in the past it *might* be a good idea to have one or two packagers that are also kind of wiki-masters for "PackageMaintainers/*" -- those could coordinates the efforts done by different people in this area of the wiki and make sure the structure and everything else is in a sane state. CU knurd From rc040203 at freenet.de Tue May 22 12:07:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 22 May 2007 14:07:34 +0200 Subject: koji: make build non-interactive? In-Reply-To: <4652DB68.1050103@leemhuis.info> References: <20070522100418.GC26847@neu.nirvana> <4652C379.10708@leemhuis.info> <645d17210705220452y84d12d5u6777cf58771e72d8@mail.gmail.com> <4652DB68.1050103@leemhuis.info> Message-ID: <1179835654.4735.1414.camel@mccallum.corsepiu.local> On Tue, 2007-05-22 at 14:00 +0200, Thorsten Leemhuis wrote: > On 22.05.2007 13:52, Jonathan Underwood wrote: > > On 22/05/07, Thorsten Leemhuis wrote: > >> There is also some stuff on > >> http://fedoraproject.org/wiki/Koji/UsingKoji > > > > Groan. > > Yet again, documentation hidden from view. > > Why is there no mention of this documentation at > > /me found it accidentally with google ;-) Then you were lucky, when I googled, all I found was some czech pages ;) > > http://fedoraproject.org/wiki/PackageMaintainers > > That's the first place I go to look for information when, as a > > packager, I am unsure about something. > > I'll add a link now, but really would like to encourage people to not > > hide documentation away! > > My 2 cent: for this and other problems we faced with the wiki docs in > the past it *might* be a good idea to have one or two packagers that are > also kind of wiki-masters for "PackageMaintainers/*" -- those could > coordinates the efforts done by different people in this area of the > wiki and make sure the structure and everything else is in a sane state. IMO, it would be better to ship such docs as part of an rpm, such that users can dig it up locally, instead of having to chase moving targets such as wikis. Ralf From dennis at ausil.us Tue May 22 11:28:10 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 22 May 2007 06:28:10 -0500 Subject: splitting a package into many (src.rpm wise): resubmit or special handling? In-Reply-To: <20070522101349.GD26847@neu.nirvana> References: <20070522101349.GD26847@neu.nirvana> Message-ID: <200705220628.11126.dennis@ausil.us> Once upon a time Tuesday 22 May 2007, Axel Thimm wrote: > This is about nx which is a conglomeration of several (8) different > source tarballs. This is a historical design which has some drawbacks > like having to rebuild all 8 "subpackages" when only one changes. > > Now, technically splitting the (source) package into 8 (source) > packages is less the problem, I'm more afraid of having to submit all > 8 pieces and wait for reviews of each one of them. Any chance this > could be special handled by a cvsadmin? Does fesco or some other > instance need to approve? You need to have this go through review. Dennis From pmatilai at laiskiainen.org Tue May 22 12:47:09 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 22 May 2007 15:47:09 +0300 (EEST) Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <20070521210906.GJ2486@nostromo.devel.redhat.com> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> <20070519163244.4cd70e5b.bugs.michael@gmx.net> <1179760611.18583.29.camel@localhost.localdomain> <20070521210906.GJ2486@nostromo.devel.redhat.com> Message-ID: On Mon, 21 May 2007, Bill Nottingham wrote: >> Is anyone reporting these as "things we shouldn't have to care about" to >> rpm-maint@ or the appropriate bugzilla? > > It's somewhat tricky to fix - you're asking rpm-the-parser to either > a) elide anything that starts with '#' from all scriplets, even though > it may be valid in some interpreter > b) conditionally elide it based on what the scriplet interpreter is > > Not sure it's 100% worth the change from stupid-but-predictable. Yup, I don't think it's worth it. To really fix it you'd need ending tags for the scripts, eg %preun ... %endpreun or something. Not sure if that's worth the trouble either :) Just advice in the packaging guidelines to write scriptlet comments *in* the script where needed, using the scriptlet interpreters comment format. - Panu - From tcallawa at redhat.com Tue May 22 12:52:17 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 May 2007 07:52:17 -0500 Subject: [PATCH] Update to branches system to match recent DistTag change In-Reply-To: <1179808764.3109.13.camel@ignacio.lan> References: <1179808764.3109.13.camel@ignacio.lan> Message-ID: <1179838337.6254.269.camel@localhost.localdomain> On Tue, 2007-05-22 at 00:39 -0400, Ignacio Vazquez-Abrams wrote: > This patch makes the branches system in cvs define the same tag as the > buildsys-macros package now does. It also cleans out a bit of cruft that > could cause a rpm command line to be too long. Ignacio, I don't think thats quite correct. $(DIST) would be .fc7 We want to define fc7 as 1, not .fc7. ~spot From jkeating at redhat.com Tue May 22 14:13:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 May 2007 10:13:49 -0400 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> Message-ID: <200705221013.53223.jkeating@redhat.com> On Tuesday 22 May 2007 5:42:08 am Jonathan Underwood wrote: > Would it be possible to rationalize all this a bit to provide a single > URL and a sensible archiving hierarchy for the logs? There is on the file system: http://koji.fedoraproject.org/packages/koji/1.2.0/3.fc7/data/logs/ The URL structure is ///data/logs// -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Tue May 22 14:23:47 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 22 May 2007 15:23:47 +0100 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <200705221013.53223.jkeating@redhat.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200705221013.53223.jkeating@redhat.com> Message-ID: <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> On 22/05/07, Jesse Keating wrote: > On Tuesday 22 May 2007 5:42:08 am Jonathan Underwood wrote: > > Would it be possible to rationalize all this a bit to provide a single > > URL and a sensible archiving hierarchy for the logs? > > There is on the file system: > > http://koji.fedoraproject.org/packages/koji/1.2.0/3.fc7/data/logs/ > > The URL structure is ///data/logs// Right, but short of sending this mail, that's not readily accesible. I suspected such a thing would exist. So I went to http://koji.fedoraproject.org/koji, clicked Packages at the top, clicked on my relevant package and build, which eventually gets me here: http://koji.fedoraproject.org/koji/buildinfo?buildID=6968 ./.. and that's where I'd expect to see something about the build logs, but I don't. So unless I was "in the know" about the URL you gave above, I'd have no way of finding the build logs. So my suggestion really relates to usability, everything is there under the hood. J. From jkeating at redhat.com Tue May 22 14:32:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 May 2007 10:32:28 -0400 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200705221013.53223.jkeating@redhat.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> Message-ID: <200705221032.29028.jkeating@redhat.com> On Tuesday 22 May 2007 10:23:47 am Jonathan Underwood wrote: > So unless I was "in the know" about the URL you gave above, I'd have > no way of finding the build logs. So my suggestion really relates to > usability, everything is there under the hood. Suggestions with patches are even more helpful (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue May 22 14:43:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 May 2007 10:43:30 -0400 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <200705221032.29028.jkeating@redhat.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> <200705221032.29028.jkeating@redhat.com> Message-ID: <200705221043.31088.jkeating@redhat.com> On Tuesday 22 May 2007 10:32:28 am Jesse Keating wrote: > Suggestions with patches are even more helpful (: But seriously, failing that, mailing lists are horrible places to track suggestions. I appreciate that there is thought going into how we can improve koji, and discussion is good. Filing an RFE at http://hosted.fedoraproject.org/projects/koji would be even better so that we don't forget about this. Your FAS username/password works for logging in. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Tue May 22 14:58:09 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 22 May 2007 15:58:09 +0100 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <200705221043.31088.jkeating@redhat.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> <200705221032.29028.jkeating@redhat.com> <200705221043.31088.jkeating@redhat.com> Message-ID: <645d17210705220758l55e9f5a1lf03e401b1de880e9@mail.gmail.com> On 22/05/07, Jesse Keating wrote: > On Tuesday 22 May 2007 10:32:28 am Jesse Keating wrote: > > Suggestions with patches are even more helpful (: > > But seriously, failing that, mailing lists are horrible places to track > suggestions. I appreciate that there is thought going into how we can > improve koji, and discussion is good. Filing an RFE at > http://hosted.fedoraproject.org/projects/koji would be even better so that we > don't forget about this. Your FAS username/password works for logging in. OK, ticket submitted. From Axel.Thimm at ATrpms.net Tue May 22 14:59:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 22 May 2007 16:59:10 +0200 Subject: Package announcements pre-bodhi Message-ID: <20070522145910.GC6016@neu.nirvana> Hi, I'd like to make a package announcment (about an incompatible config change in fail2ban). What's the procedure before using bodhi? Is there some template I could use to create something that I can send to f-p-a? I remember that there was some discussion a year ago when Hans was the only one that made the only two or so announcements of fedora extras packages, so it certainly is no well-known path. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eric.tanguy at univ-nantes.fr Tue May 22 14:59:51 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Tue, 22 May 2007 16:59:51 +0200 Subject: Package view Message-ID: <1179845991.29096.7.camel@bureau.maison> I would like to know how it could be possible to see for a given package to see which versions are available for all the fedora distros including EPEL. Is it possible ? Thanks Eric From nicolas.mailhot at laposte.net Tue May 22 15:00:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 22 May 2007 17:00:31 +0200 (CEST) Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <200705221043.31088.jkeating@redhat.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> <200705221032.29028.jkeating@redhat.com> <200705221043.31088.jkeating@redhat.com> Message-ID: <17204.192.54.193.51.1179846031.squirrel@rousalka.dyndns.org> Le Mar 22 mai 2007 16:43, Jesse Keating a ?crit : > But seriously, failing that, mailing lists are horrible places to > track > suggestions. I appreciate that there is thought going into how we can > improve koji, and discussion is good. Filing an RFE at > http://hosted.fedoraproject.org/projects/koji would be even better so > that we don't forget about this. I've already filled a bunch of RFE's and IIRC better build log access was included -- Nicolas Mailhot From karsten at redhat.com Tue May 22 15:01:28 2007 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 22 May 2007 17:01:28 +0200 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200705221013.53223.jkeating@redhat.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> Message-ID: <465305C8.4070304@redhat.com> Jonathan Underwood schrieb: > On 22/05/07, Jesse Keating wrote: >> On Tuesday 22 May 2007 5:42:08 am Jonathan Underwood wrote: >> > Would it be possible to rationalize all this a bit to provide a single >> > URL and a sensible archiving hierarchy for the logs? >> >> There is on the file system: >> >> http://koji.fedoraproject.org/packages/koji/1.2.0/3.fc7/data/logs/ >> >> The URL structure is ///data/logs// > > Right, but short of sending this mail, that's not readily accesible. I > suspected such a thing would exist. So I went to > http://koji.fedoraproject.org/koji, clicked Packages at the top, > clicked on my relevant package and build, which eventually gets me > here: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=6968 > > ./.. and that's where I'd expect to see something about the build > logs, but I don't. > > So unless I was "in the know" about the URL you gave above, I'd have > no way of finding the build logs. So my suggestion really relates to > usability, everything is there under the hood. > > J. The logs are somewhat hidden, but you can find them if you click on 'Tasks' in the above URL and then on one of the 'Descendent tasks' Karsten From nicolas.mailhot at laposte.net Tue May 22 15:10:10 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 22 May 2007 17:10:10 +0200 (CEST) Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <465305C8.4070304@redhat.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200705221013.53223.jkeating@redhat.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> <465305C8.4070304@redhat.com> Message-ID: <62057.192.54.193.51.1179846610.squirrel@rousalka.dyndns.org> Le Mar 22 mai 2007 17:01, Karsten Hopp a ?crit : >> So unless I was "in the know" about the URL you gave above, I'd have >> no way of finding the build logs. So my suggestion really relates to >> usability, everything is there under the hood. I found them all by myself the other day just by using the old "remove filename from download URL and look where you can browse trick" > The logs are somewhat hidden, but you can find them if you click on > 'Tasks' in the above URL and then on one of the 'Descendent tasks' Given that koji is a build farm you'd have thought build info would be more easily reachable. -- Nicolas Mailhot From jkeating at redhat.com Tue May 22 15:14:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 May 2007 11:14:17 -0400 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <17204.192.54.193.51.1179846031.squirrel@rousalka.dyndns.org> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200705221043.31088.jkeating@redhat.com> <17204.192.54.193.51.1179846031.squirrel@rousalka.dyndns.org> Message-ID: <200705221114.17415.jkeating@redhat.com> On Tuesday 22 May 2007 11:00:31 Nicolas Mailhot wrote: > Le Mar 22 mai 2007 16:43, Jesse Keating a ?crit : > > But seriously, failing that, mailing lists are horrible places to > > track > > suggestions. I appreciate that there is thought going into how we can > > improve koji, and discussion is good. Filing an RFE at > > http://hosted.fedoraproject.org/projects/koji would be even better so > > that we don't forget about this. > > I've already filled a bunch of RFE's and IIRC better build log access > was included Seems I forgot to setup the components and owners and such in the Trac space. My bad. Doing that now. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Tue May 22 15:14:59 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 22 May 2007 10:14:59 -0500 (CDT) Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <62057.192.54.193.51.1179846610.squirrel@rousalka.dyndns.org> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200705221013.53223.jkeating@redhat.com> <645d17210705220723s725802f8i431ae467b38289f@mail.gmail.com> <465305C8.4070304@redhat.com> <62057.192.54.193.51.1179846610.squirrel@rousalka.dyndns.org> Message-ID: On Tue, 22 May 2007, Nicolas Mailhot wrote: >> The logs are somewhat hidden, but you can find them if you click on >> 'Tasks' in the above URL and then on one of the 'Descendent tasks' > > Given that koji is a build farm you'd have thought build info would be > more easily reachable. Seems realistic enough. You have to gather eggs and milk cows on a real farm! ;-) Jima From opensource at till.name Tue May 22 15:37:12 2007 From: opensource at till.name (Till Maas) Date: Tue, 22 May 2007 17:37:12 +0200 Subject: Koji suggestion: making build logs much more accessible. In-Reply-To: <645d17210705220758l55e9f5a1lf03e401b1de880e9@mail.gmail.com> References: <645d17210705220242j414d1a2paec116ef93ded0d8@mail.gmail.com> <200705221043.31088.jkeating@redhat.com> <645d17210705220758l55e9f5a1lf03e401b1de880e9@mail.gmail.com> Message-ID: <200705221737.13352.opensource@till.name> On Di Mai 22 2007, Jonathan Underwood wrote: > OK, ticket submitted. I submitted a patch, but I do not know, whether it is completely correct. Maybe someone with a running koji can test it. Regards, Till From tjanouse at redhat.com Tue May 22 15:42:18 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Tue, 22 May 2007 17:42:18 +0200 Subject: Status of the merge In-Reply-To: <20070504174140.GA17225@redhat.com> References: <20070502223952.1F1761801A3@magilla.sf.frob.com> <200705021542.47760.jkeating@redhat.com> <20070504105426.GA11699@redhat.com> <1178293061.2785.4.camel@aglarond.local> <20070504174140.GA17225@redhat.com> Message-ID: <20070522154218.GA10864@redhat.com> Hi, On Fri, May 04, 2007 at 07:41:40PM +0200, Tomas Janousek wrote: > On Fri, May 04, 2007 at 11:37:41AM -0400, Jeremy Katz wrote: > > > For all who use private branches, the following patch may be helpful. I added > > > it to RH's Makefile.common recently, being inspired by `make zstreams'. > > > > This seems okay, but can you also add appropriate documentation to the > > help target? > > Sorry, new patch: Jeremy, what's the status of this one? -- TJ. (Brno, CZ), BaseOS, Red Hat From icon at fedoraproject.org Tue May 22 16:25:16 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 22 May 2007 12:25:16 -0400 Subject: Policy about network-listening daemons running as root? Message-ID: Hi, all: Do we have a policy about network-listening daemons not running as root? Not according to my perusal of fedoraproject.org, but I wanted to verify in case it's one of the "unwritten rules." Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From j.w.r.degoede at hhs.nl Tue May 22 16:50:58 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 22 May 2007 18:50:58 +0200 Subject: Policy about network-listening daemons running as root? In-Reply-To: References: Message-ID: <46531F72.3090908@hhs.nl> Konstantin Ryabitsev wrote: > Hi, all: > > Do we have a policy about network-listening daemons not running as > root? Not according to my perusal of fedoraproject.org, but I wanted > to verify in case it's one of the "unwritten rules." > This clearly falls under the unwritten use your common sense rule. IOW no daemon / service should run as root unless it absolutely must, and when not running as root it should have its own user, not use a system user shared with other daemons. Regards, Hans From dwalsh at redhat.com Tue May 22 16:52:43 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 22 May 2007 12:52:43 -0400 Subject: Policy about network-listening daemons running as root? In-Reply-To: <46531F72.3090908@hhs.nl> References: <46531F72.3090908@hhs.nl> Message-ID: <46531FDB.1020009@redhat.com> Hans de Goede wrote: > Konstantin Ryabitsev wrote: >> Hi, all: >> >> Do we have a policy about network-listening daemons not running as >> root? Not according to my perusal of fedoraproject.org, but I wanted >> to verify in case it's one of the "unwritten rules." >> > > This clearly falls under the unwritten use your common sense rule. IOW > no daemon / service should run as root unless it absolutely must, and > when not running as root it should have its own user, not use a system > user shared with other daemons. > > Regards, If it runs as root, it should drop capabilities that it does not need, and it should have an SELinux policy to confine it. Of course if it runs as non-root, it should have an SELinux policy to confine it. These are shoulds not musts. > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From tcallawa at redhat.com Tue May 22 16:53:07 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 May 2007 11:53:07 -0500 Subject: Policy about network-listening daemons running as root? In-Reply-To: <46531FDB.1020009@redhat.com> References: <46531F72.3090908@hhs.nl> <46531FDB.1020009@redhat.com> Message-ID: <1179852787.6254.292.camel@localhost.localdomain> On Tue, 2007-05-22 at 12:52 -0400, Daniel J Walsh wrote: > If it runs as root, it should drop capabilities that it does not need, > and it should have an SELinux policy to confine it. Of course if it > runs as non-root, it should have an SELinux policy to confine it. > > These are shoulds not musts. Dan, is there a simple guide for packagers on how to make SELinux policy for these cases? Also, is it possible to package policy as part of an application, or do changes still need to go in the master policy package? ~spot From Fedora at FamilleCollet.com Tue May 22 17:02:35 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 22 May 2007 19:02:35 +0200 Subject: [Guidelines Change] PHP Changes In-Reply-To: <20070521212825.77fd7f96@python3.es.egwn.lan> References: <1179773365.6254.252.camel@localhost.localdomain> <20070521212825.77fd7f96@python3.es.egwn.lan> Message-ID: <4653222B.5020402@FamilleCollet.com> Matthias Saou a ?crit : > Unfortunately, I just noticed that the RHEL5 packages are "half way". > The php-common package provides both : > > php-api = 20041225 > php-zend-abi = 20050922 > > ...but no "php(zend-abi)" or "php(api)" versions of the same values. And no /etc/rpm/macros.php So same spec work for FC6 and EL5. Of course EL5 build will only requires php-api. > > To make things easier for EPEL, I'll file a RFE for the next RHEL5 PHP > update to provide those... Thanks for that. Remi. From dwalsh at redhat.com Tue May 22 17:16:35 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 22 May 2007 13:16:35 -0400 Subject: Policy about network-listening daemons running as root? In-Reply-To: <1179852787.6254.292.camel@localhost.localdomain> References: <46531F72.3090908@hhs.nl> <46531FDB.1020009@redhat.com> <1179852787.6254.292.camel@localhost.localdomain> Message-ID: <46532573.2040805@redhat.com> Tom "spot" Callaway wrote: > On Tue, 2007-05-22 at 12:52 -0400, Daniel J Walsh wrote: > > >> If it runs as root, it should drop capabilities that it does not need, >> and it should have an SELinux policy to confine it. Of course if it >> runs as non-root, it should have an SELinux policy to confine it. >> >> These are shoulds not musts. >> > > Dan, is there a simple guide for packagers on how to make SELinux policy > for these cases? > > Also, is it possible to package policy as part of an application, or do > changes still need to go in the master policy package? > > ~spot > > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > I am writing up a guide on writing policy for Red Hat Magazine. I have a presentation on this at http://people.redhat.com/dwalsh/SELinux/Presentations/PolicyGeneration.pdf The latest policycoreutils-gui has a new tool (polgengui) , Which is launchable from system-config-selinux to help you build a policy. As far as shipping policy inside or RPM http://fedoraproject.org/wiki/PackagingDrafts/SELinux Is the best we have right now. Dan From ivazqueznet at gmail.com Tue May 22 17:23:50 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 22 May 2007 13:23:50 -0400 Subject: [PATCH] Update to branches system to match recent DistTag change In-Reply-To: <1179838337.6254.269.camel@localhost.localdomain> References: <1179808764.3109.13.camel@ignacio.lan> <1179838337.6254.269.camel@localhost.localdomain> Message-ID: <1179854630.3109.16.camel@ignacio.lan> On Tue, 2007-05-22 at 07:52 -0500, Tom "spot" Callaway wrote: > On Tue, 2007-05-22 at 00:39 -0400, Ignacio Vazquez-Abrams wrote: > > This patch makes the branches system in cvs define the same tag as the > > buildsys-macros package now does. It also cleans out a bit of cruft that > > could cause a rpm command line to be too long. > > Ignacio, I don't think thats quite correct. > > $(DIST) would be .fc7 > We want to define fc7 as 1, not .fc7. You're right, I missed the field shift in the cut earlier. Updated patch attached. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: dist-fix-2.patch Type: text/x-patch Size: 1584 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 tcallawa at redhat.com Tue May 22 17:27:03 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 May 2007 12:27:03 -0500 Subject: [PATCH] Update to branches system to match recent DistTag change In-Reply-To: <1179854630.3109.16.camel@ignacio.lan> References: <1179808764.3109.13.camel@ignacio.lan> <1179838337.6254.269.camel@localhost.localdomain> <1179854630.3109.16.camel@ignacio.lan> Message-ID: <1179854823.6254.295.camel@localhost.localdomain> On Tue, 2007-05-22 at 13:23 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2007-05-22 at 07:52 -0500, Tom "spot" Callaway wrote: > > On Tue, 2007-05-22 at 00:39 -0400, Ignacio Vazquez-Abrams wrote: > > > This patch makes the branches system in cvs define the same tag as the > > > buildsys-macros package now does. It also cleans out a bit of cruft that > > > could cause a rpm command line to be too long. > > > > Ignacio, I don't think thats quite correct. > > > > $(DIST) would be .fc7 > > We want to define fc7 as 1, not .fc7. > > You're right, I missed the field shift in the cut earlier. Updated patch > attached. Target isn't quite right either. Target for Fedora 7 is dist-fc7-updates-candidate, the macro define is fc7. ~spot From dwalsh at redhat.com Tue May 22 17:41:29 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 22 May 2007 13:41:29 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? Message-ID: <46532B49.9020307@redhat.com> SHELLS(5) Linux Programmer?s Manual SHELLS(5) NAME shells - pathnames of valid login shells DESCRIPTION /etc/shells is a text file which contains the full pathnames of valid login shells. This file is consulted by chsh(1) and available to be queried by other programs. Be aware that there are programs which consult this file to find out if a user is a normal user. E.g.: ftp daemons traditionally disallow access to users with shells not included in this file. EXAMPLE /etc/shells may contain the following paths: /bin/sh /bin/csh FILES /etc/shells > grep ftp /etc/shells ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin This has led us to hack up the genhomedircon script to remove this from valid shells. From ruben at rubenkerkhof.com Tue May 22 17:50:03 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Tue, 22 May 2007 19:50:03 +0200 Subject: Branching done ?? In-Reply-To: <20070518182125.GC19544@nostromo.devel.redhat.com> References: <464DC421.2020903@hhs.nl> <1179500939.3046.9.camel@vader.jdub.homelinux.org> <464DC6DD.8080402@hhs.nl> <20070518181957.GB19544@nostromo.devel.redhat.com> <20070518182125.GC19544@nostromo.devel.redhat.com> Message-ID: <38EAEABE-1ACC-4EB6-8490-28666386F43E@rubenkerkhof.com> On 18-mei-2007, at 20:21, Bill Nottingham wrote: > Bill Nottingham (notting at redhat.com) said: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> However a new package for which the dirs have been created last >>> night (iow >>> shortly before the branch) doesn't have an F-7, the involved >>> package is >>> "ants", the same probably goes for "rott" (which I still have to >>> import) as >>> rott was created at the same time. >> >> The branch was done for every package that had shipped in rawhide. I >> suspect things added in the interim from the last push are left out. > > ... and I'll get to this in the next couple of hours. > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers Hi Bill, Any luck with this? I've got a few (new) packages with a missing F-7 branch as well: perl-IO-AIO, perl-Danga-Socket and perl-Sys-Syscall Ruben From ajackson at redhat.com Tue May 22 17:52:07 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 22 May 2007 13:52:07 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <46532B49.9020307@redhat.com> References: <46532B49.9020307@redhat.com> Message-ID: <1179856327.18583.78.camel@localhost.localdomain> On Tue, 2007-05-22 at 13:41 -0400, Daniel J Walsh wrote: > > grep ftp /etc/shells > ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin > > This has led us to hack up the genhomedircon script to remove this from > valid shells. Because if you use /sbin/nologin, rather than say /bin/false, you get a failure message in syslog. - ajax From ivazqueznet at gmail.com Tue May 22 17:54:32 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 22 May 2007 13:54:32 -0400 Subject: [RFC] Rethinking the branches system? (was: Re: [PATCH] Update to branches system to match recent DistTag change) In-Reply-To: <1179854823.6254.295.camel@localhost.localdomain> References: <1179808764.3109.13.camel@ignacio.lan> <1179838337.6254.269.camel@localhost.localdomain> <1179854630.3109.16.camel@ignacio.lan> <1179854823.6254.295.camel@localhost.localdomain> Message-ID: <1179856472.3109.27.camel@ignacio.lan> On Tue, 2007-05-22 at 12:27 -0500, Tom "spot" Callaway wrote: > Target isn't quite right either. > > Target for Fedora 7 is dist-fc7-updates-candidate, the macro define is > fc7. Again with the rightness. The proper fix is going to involve adding another field, and the other change I'd like to implement adds yet another one, so maybe we've finally outgrown the current implementation branches system. I certainly don't mind just adding more fields, but the maintainability will suffer. I don't mind tossing in a bit of documentation with the next patch, but I want to elicit the opinions of others about this. -- Ignacio Vazquez-Abrams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Tue May 22 18:00:01 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 May 2007 13:00:01 -0500 Subject: [RFC] Rethinking the branches system? (was: Re: [PATCH] Update to branches system to match recent DistTag change) In-Reply-To: <1179856472.3109.27.camel@ignacio.lan> References: <1179808764.3109.13.camel@ignacio.lan> <1179838337.6254.269.camel@localhost.localdomain> <1179854630.3109.16.camel@ignacio.lan> <1179854823.6254.295.camel@localhost.localdomain> <1179856472.3109.27.camel@ignacio.lan> Message-ID: <1179856801.6254.299.camel@localhost.localdomain> On Tue, 2007-05-22 at 13:54 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2007-05-22 at 12:27 -0500, Tom "spot" Callaway wrote: > > Target isn't quite right either. > > > > Target for Fedora 7 is dist-fc7-updates-candidate, the macro define is > > fc7. > > Again with the rightness. > > The proper fix is going to involve adding another field, and the other > change I'd like to implement adds yet another one, so maybe we've > finally outgrown the current implementation branches system. I certainly > don't mind just adding more fields, but the maintainability will suffer. Or, sed the . off the disttag. ~spot From mikeb at redhat.com Tue May 22 18:03:24 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 22 May 2007 14:03:24 -0400 Subject: [PATCH] Update to branches system to match recent DistTag change In-Reply-To: <1179854630.3109.16.camel@ignacio.lan> References: <1179808764.3109.13.camel@ignacio.lan> <1179838337.6254.269.camel@localhost.localdomain> <1179854630.3109.16.camel@ignacio.lan> Message-ID: <1179857004.15323.3.camel@liffey.home> On Tue, 2007-05-22 at 13:23 -0400, Ignacio Vazquez-Abrams wrote: > ## use this to build an srpm locally > srpm: sources $(TARGETS) > - $(RPM_WITH_DIRS) $(DIST_DEFINES) --nodeps -bs $(SPECFILE) > + $(RPM_WITH_DIRS) --nodeps -bs $(SPECFILE) $(DIST_DEFINES) should not be removed from the srpm target. This is the target that Koji calls to build the srpm, and if %{dist} is not defined the N-V-R of the srpm will not contain the %{dist} macro, and you'll get N-V-R mismatches when the binary rpms are built. From dwalsh at redhat.com Tue May 22 18:03:54 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 22 May 2007 14:03:54 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <1179856327.18583.78.camel@localhost.localdomain> References: <46532B49.9020307@redhat.com> <1179856327.18583.78.camel@localhost.localdomain> Message-ID: <4653308A.7050707@redhat.com> Adam Jackson wrote: > On Tue, 2007-05-22 at 13:41 -0400, Daniel J Walsh wrote: > > >> > grep ftp /etc/shells >> ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin >> >> This has led us to hack up the genhomedircon script to remove this from >> valid shells. >> > > Because if you use /sbin/nologin, rather than say /bin/false, you get a > failure message in syslog. > > - ajax > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > I guess a better question would be how to tell the difference between a valid "user" and a "service" on the system. Currently SELinux checks if uid < 500 (GID_MIN from /etc/login.defs) or a shell from /etc/shells - /sbin/nologin. This is used to make sure the labeling of the home directory is done properly. From mclasen at redhat.com Tue May 22 18:05:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 May 2007 14:05:35 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <4653308A.7050707@redhat.com> References: <46532B49.9020307@redhat.com> <1179856327.18583.78.camel@localhost.localdomain> <4653308A.7050707@redhat.com> Message-ID: <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> On Tue, 2007-05-22 at 14:03 -0400, Daniel J Walsh wrote: > > > I guess a better question would be how to tell the difference between a > valid "user" and a "service" on the system. Currently SELinux checks if > uid < 500 (GID_MIN from /etc/login.defs) or a shell from /etc/shells - > /sbin/nologin. > > This is used to make sure the labeling of the home directory is done > properly. The same issue has come up in gdm recently, where a database user showed up in the user list, because it was > 500 and had a "valid shell" (which was /sbin/nologin). We have changed gdm to not consider nologin a valid shell even if it is in /etc/shells. This is all a bit of an undefined mess of traditional behaviours... From j.w.r.degoede at hhs.nl Tue May 22 18:24:01 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 22 May 2007 20:24:01 +0200 Subject: new packages (added after the merge) fail to build in koji?? Message-ID: <46533541.3040903@hhs.nl> Hi, Today avr-gcc got approved, and a cvs tree created, but it fails to build in koji with this interesting message: "BuildError: package avr-gcc not in list for tag dist-fc7-updates-candidate" See: http://koji.fedoraproject.org/koji/taskinfo?taskID=14328 Regards, Hans From limb at jcomserv.net Tue May 22 18:08:42 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 22 May 2007 13:08:42 -0500 (CDT) Subject: new packages (added after the merge) fail to build in koji?? In-Reply-To: <46533541.3040903@hhs.nl> References: <46533541.3040903@hhs.nl> Message-ID: <29188.65.192.24.190.1179857322.squirrel@mail.jcomserv.net> I got this too for nagi, et. al. I sent a message to rel-eng in case I missed something. Anyone besides Hans and I running into this? > Hi, > > Today avr-gcc got approved, and a cvs tree created, but it fails to build > in > koji with this interesting message: "BuildError: package avr-gcc not in > list > for tag dist-fc7-updates-candidate" > > See: > http://koji.fedoraproject.org/koji/taskinfo?taskID=14328 > > Regards, > > Hans > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From ivazqueznet at gmail.com Tue May 22 18:18:07 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 22 May 2007 14:18:07 -0400 Subject: [PATCH] Update to branches system to match recent DistTag change In-Reply-To: <1179857004.15323.3.camel@liffey.home> References: <1179808764.3109.13.camel@ignacio.lan> <1179838337.6254.269.camel@localhost.localdomain> <1179854630.3109.16.camel@ignacio.lan> <1179857004.15323.3.camel@liffey.home> Message-ID: <1179857887.3109.32.camel@ignacio.lan> On Tue, 2007-05-22 at 14:03 -0400, Mike Bonnet wrote: > On Tue, 2007-05-22 at 13:23 -0400, Ignacio Vazquez-Abrams wrote: > > ## use this to build an srpm locally > > srpm: sources $(TARGETS) > > - $(RPM_WITH_DIRS) $(DIST_DEFINES) --nodeps -bs $(SPECFILE) > > + $(RPM_WITH_DIRS) --nodeps -bs $(SPECFILE) > > $(DIST_DEFINES) should not be removed from the srpm target. This is the > target that Koji calls to build the srpm, and if %{dist} is not defined > the N-V-R of the srpm will not contain the %{dist} macro, and you'll get > N-V-R mismatches when the binary rpms are built. This is from Makefile.common, before the srpm target is defined: *** ifndef RPM_WITH_DIRS RPM_WITH_DIRS = $(RPM) $(RPM_DEFINES) endif *** This is from even earlier in the same file: *** ifndef RPM_DEFINES RPM_DEFINES = --define "_sourcedir $(SOURCEDIR)" \ --define "_builddir $(BUILDDIR)" \ --define "_srcrpmdir $(SRCRPMDIR)" \ --define "_rpmdir $(RPMDIR)" \ $(DIST_DEFINES) endif *** Does koji define either RPM_WITH_DIRS or RPM_DEFINES? -- Ignacio Vazquez-Abrams -------------- 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 sgrubb at redhat.com Tue May 22 18:17:53 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 22 May 2007 14:17:53 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <46532B49.9020307@redhat.com> References: <46532B49.9020307@redhat.com> Message-ID: <200705221417.53460.sgrubb@redhat.com> On Tuesday 22 May 2007 13:41, Daniel J Walsh wrote: > Be aware that there are programs which consult this file to find out if > a user is a normal user. E.g.: ftp daemons traditionally disallow > access to users with shells not included in this file. Looks like bz #53963 is why it got changed from its intended purpose. Re-open the bug and agree with comment #6? ;) I wonder if there's breakage from unfixing the bug since its been 6 years of being wrong? -Steve From mikeb at redhat.com Tue May 22 18:31:02 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 22 May 2007 14:31:02 -0400 Subject: [PATCH] Update to branches system to match recent DistTag change In-Reply-To: <1179857887.3109.32.camel@ignacio.lan> References: <1179808764.3109.13.camel@ignacio.lan> <1179838337.6254.269.camel@localhost.localdomain> <1179854630.3109.16.camel@ignacio.lan> <1179857004.15323.3.camel@liffey.home> <1179857887.3109.32.camel@ignacio.lan> Message-ID: <1179858662.15323.11.camel@liffey.home> On Tue, 2007-05-22 at 14:18 -0400, Ignacio Vazquez-Abrams wrote: > On Tue, 2007-05-22 at 14:03 -0400, Mike Bonnet wrote: > > On Tue, 2007-05-22 at 13:23 -0400, Ignacio Vazquez-Abrams wrote: > > > ## use this to build an srpm locally > > > srpm: sources $(TARGETS) > > > - $(RPM_WITH_DIRS) $(DIST_DEFINES) --nodeps -bs $(SPECFILE) > > > + $(RPM_WITH_DIRS) --nodeps -bs $(SPECFILE) > > > > $(DIST_DEFINES) should not be removed from the srpm target. This is the > > target that Koji calls to build the srpm, and if %{dist} is not defined > > the N-V-R of the srpm will not contain the %{dist} macro, and you'll get > > N-V-R mismatches when the binary rpms are built. > > This is from Makefile.common, before the srpm target is defined: > > *** > ifndef RPM_WITH_DIRS > RPM_WITH_DIRS = $(RPM) $(RPM_DEFINES) > endif > *** > > This is from even earlier in the same file: > > *** > ifndef RPM_DEFINES > RPM_DEFINES = --define "_sourcedir $(SOURCEDIR)" \ > --define "_builddir $(BUILDDIR)" \ > --define "_srcrpmdir $(SRCRPMDIR)" \ > --define "_rpmdir $(RPMDIR)" \ > $(DIST_DEFINES) > endif > *** > > Does koji define either RPM_WITH_DIRS or RPM_DEFINES? Ahh, no it doesn't. All is well then. Thanks. From dwalsh at redhat.com Tue May 22 18:32:37 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 22 May 2007 14:32:37 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> References: <46532B49.9020307@redhat.com> <1179856327.18583.78.camel@localhost.localdomain> <4653308A.7050707@redhat.com> <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> Message-ID: <46533745.9050600@redhat.com> Matthias Clasen wrote: > On Tue, 2007-05-22 at 14:03 -0400, Daniel J Walsh wrote: > > >>> >>> >> I guess a better question would be how to tell the difference between a >> valid "user" and a "service" on the system. Currently SELinux checks if >> uid < 500 (GID_MIN from /etc/login.defs) or a shell from /etc/shells - >> /sbin/nologin. >> >> This is used to make sure the labeling of the home directory is done >> properly. >> > > The same issue has come up in gdm recently, where a database user showed > up in the user list, because it was > 500 and had a "valid shell" (which > was /sbin/nologin). We have changed gdm to not consider nologin a valid > shell even if it is in /etc/shells. > > This is all a bit of an undefined mess of traditional behaviours... > > Steve Grubb, found this bugzilla https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=53963 Which discusses the addition. > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From smooge at gmail.com Tue May 22 18:38:44 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 22 May 2007 12:38:44 -0600 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <46533745.9050600@redhat.com> References: <46532B49.9020307@redhat.com> <1179856327.18583.78.camel@localhost.localdomain> <4653308A.7050707@redhat.com> <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> <46533745.9050600@redhat.com> Message-ID: <80d7e4090705221138j4159cb3dhfc07764f3d1d74b8@mail.gmail.com> On 5/22/07, Daniel J Walsh wrote: > Matthias Clasen wrote: > > On Tue, 2007-05-22 at 14:03 -0400, Daniel J Walsh wrote: > > > > > >>> > >>> > >> I guess a better question would be how to tell the difference between a > >> valid "user" and a "service" on the system. Currently SELinux checks if > >> uid < 500 (GID_MIN from /etc/login.defs) or a shell from /etc/shells - > >> /sbin/nologin. > >> > >> This is used to make sure the labeling of the home directory is done > >> properly. > >> > > > > The same issue has come up in gdm recently, where a database user showed > > up in the user list, because it was > 500 and had a "valid shell" (which > > was /sbin/nologin). We have changed gdm to not consider nologin a valid > > shell even if it is in /etc/shells. > > > > This is all a bit of an undefined mess of traditional behaviours... > > > > > Steve Grubb, found this bugzilla > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=53963 > > Which discusses the addition. > > A fix I had to do at a certain location was to basically have a badlogin and a nologin. The nologin was in the /etc/shells and the badlogin was not. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sgrubb at redhat.com Tue May 22 18:37:19 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 22 May 2007 14:37:19 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <46533745.9050600@redhat.com> References: <46532B49.9020307@redhat.com> <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> <46533745.9050600@redhat.com> Message-ID: <200705221437.19813.sgrubb@redhat.com> On Tuesday 22 May 2007 14:32, Daniel J Walsh wrote: > Which discusses the addition. I'd say that chsh (and anything else that cares) should be special cased to allow /sbin/nologin and nologin removed from /etc/shells. -Steve From pjones at redhat.com Tue May 22 19:24:17 2007 From: pjones at redhat.com (Peter Jones) Date: Tue, 22 May 2007 15:24:17 -0400 Subject: Comments in spec files (was Re: Plan for tomorrows (20070517) FESCO meeting) In-Reply-To: <20070521210906.GJ2486@nostromo.devel.redhat.com> References: <1179342669.5813.16.camel@lincoln> <1179362197.2746.313.camel@localhost.localdomain> <1179415114.17014.7.camel@localhost.localdomain> <1179415883.6254.74.camel@localhost.localdomain> <464EF373.7010203@poolshark.org> <20070519152119.adaf252b.bugs.michael@gmx.net> <464F00B0.3060903@poolshark.org> <464F0583.4030009@poolshark.org> <20070519163244.4cd70e5b.bugs.michael@gmx.net> <1179760611.18583.29.camel@localhost.localdomain> <20070521210906.GJ2486@nostromo.devel.redhat.com> Message-ID: <46534361.2060002@redhat.com> Bill Nottingham wrote: >> Is anyone reporting these as "things we shouldn't have to care about" to >> rpm-maint@ or the appropriate bugzilla? > > It's somewhat tricky to fix - you're asking rpm-the-parser to either > a) elide anything that starts with '#' from all scriplets, even though > it may be valid in some interpreter > b) conditionally elide it based on what the scriplet interpreter is > > Not sure it's 100% worth the change from stupid-but-predictable. Agreed it's not worth it. Also, couldn't we add a "--nobody" or somesuch instead, and make it part of the guidelines to use it when you're using "-p /sbin/ldconfig" or anything else where a body makes no sense? That seems like it would eliminate most of the cases, and the most common cases can easily be checked in rpmlint. -- Peter From coldwell at redhat.com Tue May 22 20:03:54 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Tue, 22 May 2007 16:03:54 -0400 (EDT) Subject: please tag emacs-22_0_990-1_fc7 to fc7-final Message-ID: All upstream development has been frozen since the first pretest release, 22.0.90, so by taking 22.0.990 we are getting upstream bugfixes without exposure to bugs in new features. Also, this emacs is built agains glibc-2.6-2, which in light of bug 239344, is probably a Good Thing. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From sdl.web at gmail.com Tue May 22 20:08:09 2007 From: sdl.web at gmail.com (Leo) Date: Tue, 22 May 2007 21:08:09 +0100 Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: (Chip Coldwell's message of "Tue, 22 May 2007 16:03:54 -0400 (EDT)") References: Message-ID: ----- Chip Coldwell (2007-05-22) wrote:----- > All upstream development has been frozen since the first pretest > release, 22.0.90, so by taking 22.0.990 we are getting upstream > bugfixes without exposure to bugs in new features. Also, this emacs > is built agains glibc-2.6-2, which in light of bug 239344, is probably > a Good Thing. > > Chip That would make emacs users happy ;) -- Leo (GPG Key: 9283AA3F) From jamatos at fc.up.pt Tue May 22 20:11:11 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 22 May 2007 21:11:11 +0100 Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: References: Message-ID: <200705222111.11251.jamatos@fc.up.pt> On Tuesday 22 May 2007 9:08:09 pm Leo wrote: > That would make emacs users happy ;) > > -- > Leo ? ? ? ? ? ? ? ? ? ? ? ? (GPG Key: 9283AA3F) I have been having deprivation syndromes. ;-) I was even forced to try xemacs. :-D On a more serious note thanks for the fix. -- Jos? Ab?lio From ville.skytta at iki.fi Tue May 22 20:20:46 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 22 May 2007 23:20:46 +0300 Subject: Ex-Core package Makefile.common problem in CVS In-Reply-To: <1178976492.9338.2.camel@ignacio.lan> References: <200705121230.40181.ville.skytta@iki.fi> <1178976492.9338.2.camel@ignacio.lan> Message-ID: <200705222320.46939.ville.skytta@iki.fi> On Saturday 12 May 2007, Ignacio Vazquez-Abrams wrote: > On Sat, 2007-05-12 at 12:30 +0300, Ville Skytt? wrote: > > After checking out "rpms" from cvs.fedora.redhat.com:/cvs/pkgs, ex-Core > > package branch Makefiles have issues finding Makefile.common. Ex-Extras > > packages don't have that problem - looks like "find-makefile-common" > > stuff or something similar should be applied to ex-Core branch Makefiles > > too. > > > > For example: > > $ cd shadow-utils/devel > > $ make prep > > Makefile:6: ../common/Makefile.common: No such file or directory > > make: *** No rule to make target `../common/Makefile.common'. Stop. > > Confirmed. And changing the line in Makefile > to ../../../common/Makefile.common doesn't work since it gives all sorts > of other problems. Hmm, I've been changing it to ../../common/Makefile.common and have had some success. Anyway I got tired of doing that and ran this dirty script to fix them all locally (including F-7 branches which seem to have inherited the same problem during branching): #!/bin/sh for pkg in * ; do for branch in F-7 devel ; do [ -f $pkg/$branch/Makefile ] || continue echo $pkg/$branch/Makefile grep -qF find-makefile-common $pkg/$branch/Makefile || \ sed -e "s/rpmdevtools/$pkg/g" rpmdevtools/$branch/Makefile \ > $pkg/$branch/Makefile done done From cra at WPI.EDU Tue May 22 20:20:46 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 May 2007 16:20:46 -0400 Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: References: Message-ID: <20070522202046.GP31145@angus.ind.WPI.EDU> On Tue, May 22, 2007 at 04:03:54PM -0400, Chip Coldwell wrote: > > All upstream development has been frozen since the first pretest > release, 22.0.90, so by taking 22.0.990 we are getting upstream > bugfixes without exposure to bugs in new features. Also, this emacs > is built agains glibc-2.6-2, which in light of bug 239344, is probably > a Good Thing. As long as the alternatives issues are straightened out first. The following bug was an F7Blocker until emacs-22.0.99 was removed from F7/downgraded to emacs-22.0.95-1.fc7 that is currently in rawhide: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239745 I have verified that emacs-22.0.95-1.fc7 (the one currently in rawhide) works properly with glibc-2.6-2 (due in rawhide tomorrow), so upgrading to 22.0.99 for that reason alone appears unnecessary. So I would say that these are the choices: 1. Don't put emacs-22.0.99 into F7, and keep emacs-22.0.95 instead. 2. Put in emacs-22.0.99 without the alternatives /usr/bin/emacs changes which cause the regression of having no /usr/bin/emacs at all after upgrades. 3. Fix the scriptlets in emacs-22.0.99 to that a /usr/bin/emacs will exist after upgrades. From sdl.web at gmail.com Tue May 22 20:25:55 2007 From: sdl.web at gmail.com (Leo) Date: Tue, 22 May 2007 21:25:55 +0100 Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: <20070522202046.GP31145@angus.ind.WPI.EDU> (Chuck Anderson's message of "Tue, 22 May 2007 16:20:46 -0400") References: <20070522202046.GP31145@angus.ind.WPI.EDU> Message-ID: ----- Chuck Anderson (2007-05-22) wrote:----- [...] > As long as the alternatives issues are straightened out first. The > following bug was an F7Blocker until emacs-22.0.99 was removed from > F7/downgraded to emacs-22.0.95-1.fc7 that is currently in rawhide: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239745 > > I have verified that emacs-22.0.95-1.fc7 (the one currently in > rawhide) works properly with glibc-2.6-2 (due in rawhide tomorrow), so > upgrading to 22.0.99 for that reason alone appears unnecessary. > > So I would say that these are the choices: > > 1. Don't put emacs-22.0.99 into F7, and keep emacs-22.0.95 instead. > > 2. Put in emacs-22.0.99 without the alternatives /usr/bin/emacs > changes which cause the regression of having no /usr/bin/emacs at all > after upgrades. > > 3. Fix the scriptlets in emacs-22.0.99 to that a /usr/bin/emacs will > exist after upgrades. Version 22.0.94 has many bugs and that's the last 22 version I have used. Not sure about 22.0.95 tho. -- Leo (GPG Key: 9283AA3F) From coldwell at redhat.com Tue May 22 20:28:50 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Tue, 22 May 2007 16:28:50 -0400 (EDT) Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: <20070522202046.GP31145@angus.ind.WPI.EDU> References: <20070522202046.GP31145@angus.ind.WPI.EDU> Message-ID: On Tue, 22 May 2007, Chuck Anderson wrote: > 3. Fix the scriptlets in emacs-22.0.99 to that a /usr/bin/emacs will > exist after upgrades. This is more complicated that it seems. Repeating what I just posted to rel-eng: The old package claims to own /usr/bin/emacs: $ rpm -qlp emacs-22.0.95-1.fc7.x86_64.rpm /usr/bin/emacs /usr/bin/emacs /usr/bin/emacs-22.0.95 /usr/bin/emacs-22.0.95-x /usr/bin/emacs-x /usr/libexec/emacs /usr/libexec/emacs/22.0.95 /usr/libexec/emacs/22.0.95/x86_64-redhat-linux-gnu /usr/share/applications/gnu-emacs.desktop /usr/share/pixmaps/emacs.png the new package does not (it is a side effect of running alternatives in the %post script): $ rpm -qlp emacs-22.0.990-1.fc7.x86_64.rpm /usr/bin/emacs-22.0.990 /usr/share/applications/gnu-emacs.desktop The scriptlets are run in the following order: %pre of new package (package install) %post of new package %preun of old package (removal of old package) %postun of old package So ... the new package in its %post scriptlet could remove the old symlink in /usr/bin (emacs -> emacs-22.0.95) and run alternatives to install a new one, but removal of the old package happens afterwards and always removes the symlink. The only hope would be to put something in the %posttrans scriptlet to check for this possibility and fix it up. Note that if you remove the old emacs package first, then install the new one in two separate rpm transactions, you will get the symlink as expected. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From notting at redhat.com Tue May 22 21:15:28 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 May 2007 17:15:28 -0400 Subject: Branching done ?? In-Reply-To: <38EAEABE-1ACC-4EB6-8490-28666386F43E@rubenkerkhof.com> References: <464DC421.2020903@hhs.nl> <1179500939.3046.9.camel@vader.jdub.homelinux.org> <464DC6DD.8080402@hhs.nl> <20070518181957.GB19544@nostromo.devel.redhat.com> <20070518182125.GC19544@nostromo.devel.redhat.com> <38EAEABE-1ACC-4EB6-8490-28666386F43E@rubenkerkhof.com> Message-ID: <20070522211528.GA25506@nostromo.devel.redhat.com> Ruben Kerkhof (ruben at rubenkerkhof.com) said: > Any luck with this? > I've got a few (new) packages with a missing F-7 branch as well: > perl-IO-AIO, perl-Danga-Socket and perl-Sys-Syscall When were they added? If they were added after the mass branch, it should be done through the 'normal' CVS process that's used for FC-6, etc. branches. Bill From notting at redhat.com Tue May 22 21:17:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 May 2007 17:17:23 -0400 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> References: <46532B49.9020307@redhat.com> <1179856327.18583.78.camel@localhost.localdomain> <4653308A.7050707@redhat.com> <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> Message-ID: <20070522211723.GB25506@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > The same issue has come up in gdm recently, where a database user showed > up in the user list, because it was > 500 and had a "valid shell" (which > was /sbin/nologin). We have changed gdm to not consider nologin a valid > shell even if it is in /etc/shells. > > This is all a bit of an undefined mess of traditional behaviours... The database user shouldn't be > 500 ; that's a packaging bug. Bill From notting at redhat.com Tue May 22 21:20:29 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 May 2007 17:20:29 -0400 Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: References: <20070522202046.GP31145@angus.ind.WPI.EDU> Message-ID: <20070522212029.GC25506@nostromo.devel.redhat.com> Chip Coldwell (coldwell at redhat.com) said: > So ... the new package in its %post scriptlet could remove the old > symlink in /usr/bin (emacs -> emacs-22.0.95) and run alternatives to > install a new one, but removal of the old package happens afterwards > and always removes the symlink. %triggerpostun -- emacs < whatever the old one ? Bill From coldwell at redhat.com Tue May 22 21:24:22 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Tue, 22 May 2007 17:24:22 -0400 (EDT) Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: <20070522212029.GC25506@nostromo.devel.redhat.com> References: <20070522202046.GP31145@angus.ind.WPI.EDU> <20070522212029.GC25506@nostromo.devel.redhat.com> Message-ID: On Tue, 22 May 2007, Bill Nottingham wrote: > Chip Coldwell (coldwell at redhat.com) said: > > So ... the new package in its %post scriptlet could remove the old > > symlink in /usr/bin (emacs -> emacs-22.0.95) and run alternatives to > > install a new one, but removal of the old package happens afterwards > > and always removes the symlink. > > %triggerpostun -- emacs < whatever the old one ? That would cause the old package %postun scriptlet to run, right? I don't think that helps since the old symlink is not removed by that scriptlet; it is removed by the main rpm process because the old emacs owns /usr/bin/emacs and the new emacs doesn't. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From notting at redhat.com Tue May 22 21:26:03 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 May 2007 17:26:03 -0400 Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: References: <20070522202046.GP31145@angus.ind.WPI.EDU> <20070522212029.GC25506@nostromo.devel.redhat.com> Message-ID: <20070522212603.GA25712@nostromo.devel.redhat.com> Chip Coldwell (coldwell at redhat.com) said: > On Tue, 22 May 2007, Bill Nottingham wrote: > > > Chip Coldwell (coldwell at redhat.com) said: > > > So ... the new package in its %post scriptlet could remove the old > > > symlink in /usr/bin (emacs -> emacs-22.0.95) and run alternatives to > > > install a new one, but removal of the old package happens afterwards > > > and always removes the symlink. > > > > %triggerpostun -- emacs < whatever the old one ? > > That would cause the old package %postun scriptlet to run, right? No. %triggerpostun -- emacs means that it should run whenever emacs that matches that version specifier is removed. Bill From jspaleta at gmail.com Tue May 22 21:46:18 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 May 2007 13:46:18 -0800 Subject: How come /sbin/nologin is in /etc/shells contradicting the man page? In-Reply-To: <20070522211723.GB25506@nostromo.devel.redhat.com> References: <46532B49.9020307@redhat.com> <1179856327.18583.78.camel@localhost.localdomain> <4653308A.7050707@redhat.com> <1179857135.8034.1.camel@dhcp83-33.boston.redhat.com> <20070522211723.GB25506@nostromo.devel.redhat.com> Message-ID: <604aa7910705221446x61c5ab41ud7a591a6cb1f6b31@mail.gmail.com> On 5/22/07, Bill Nottingham wrote: > The database user shouldn't be > 500 ; that's a packaging bug. How close are we to running out of space below 500 ? Taking all the daemon's in fedora space.. are we say 30%, 60% , 110% used up? -jef From ruben at rubenkerkhof.com Wed May 23 08:41:54 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Wed, 23 May 2007 10:41:54 +0200 Subject: Branching done ?? In-Reply-To: <20070522211528.GA25506@nostromo.devel.redhat.com> References: <464DC421.2020903@hhs.nl> <1179500939.3046.9.camel@vader.jdub.homelinux.org> <464DC6DD.8080402@hhs.nl> <20070518181957.GB19544@nostromo.devel.redhat.com> <20070518182125.GC19544@nostromo.devel.redhat.com> <38EAEABE-1ACC-4EB6-8490-28666386F43E@rubenkerkhof.com> <20070522211528.GA25506@nostromo.devel.redhat.com> Message-ID: On 22-mei-2007, at 23:15, Bill Nottingham wrote: > Ruben Kerkhof (ruben at rubenkerkhof.com) said: >> Any luck with this? >> I've got a few (new) packages with a missing F-7 branch as well: >> perl-IO-AIO, perl-Danga-Socket and perl-Sys-Syscall > > When were they added? If they were added after the mass branch, > it should be done through the 'normal' CVS process that's > used for FC-6, etc. branches. > > Bill They were added on the 16th, so AFAIKS before the merge. Ruben From lmacken at redhat.com Wed May 23 13:17:24 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 23 May 2007 09:17:24 -0400 Subject: Package announcements pre-bodhi In-Reply-To: <20070522145910.GC6016@neu.nirvana> References: <20070522145910.GC6016@neu.nirvana> Message-ID: <20070523131724.GC19280@tomservo.rh.rit.edu> On Tue, May 22, 2007 at 04:59:10PM +0200, Axel Thimm wrote: > Hi, > > I'd like to make a package announcment (about an incompatible config > change in fail2ban). What's the procedure before using bodhi? Is there > some template I could use to create something that I can send to > f-p-a? > > I remember that there was some discussion a year ago when Hans was the > only one that made the only two or so announcements of fedora extras > packages, so it certainly is no well-known path. :) There's currently no procedure defined for doing this, although I don't see a reason why you couldn't do it by hand (if you *really* wanted to), aside from the inconsistency since we aren't doing it for all updates yet. I made some modifications to the template a while back and sent it off to fedora-infra-list for review, so I guess you could use something like this: https://www.redhat.com/archives/fedora-infrastructure-list/2007-April/msg00191.html luke From coldwell at redhat.com Wed May 23 13:43:31 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Wed, 23 May 2007 09:43:31 -0400 (EDT) Subject: please tag emacs-22_0_990-1_fc7 to fc7-final In-Reply-To: <20070522212603.GA25712@nostromo.devel.redhat.com> References: <20070522202046.GP31145@angus.ind.WPI.EDU> <20070522212029.GC25506@nostromo.devel.redhat.com> <20070522212603.GA25712@nostromo.devel.redhat.com> Message-ID: On Tue, 22 May 2007, Bill Nottingham wrote: > Chip Coldwell (coldwell at redhat.com) said: > > On Tue, 22 May 2007, Bill Nottingham wrote: > > > > > Chip Coldwell (coldwell at redhat.com) said: > > > > So ... the new package in its %post scriptlet could remove the old > > > > symlink in /usr/bin (emacs -> emacs-22.0.95) and run alternatives to > > > > install a new one, but removal of the old package happens afterwards > > > > and always removes the symlink. > > > > > > %triggerpostun -- emacs < whatever the old one ? > > > > That would cause the old package %postun scriptlet to run, right? > > No. > > %triggerpostun -- emacs > > means that it should run whenever emacs that matches that version specifier > is removed. Actually, Charles R. Anderson posted a patch to that bugzilla (239745) that fixes the problem using a %ghost file. I'm leaning toward that solution (for later F-7 updates and F-8). Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From coldwell at redhat.com Wed May 23 14:34:25 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Wed, 23 May 2007 10:34:25 -0400 (EDT) Subject: please tag emacs-22_0_990-2_fc7 to fc7-final Message-ID: This build reverts all packaging changes since 22.0.95-1 (Resolves: bz239745) new pretest tarball from FSF (Resolves: bz238234) restore php-mode (Resolves: bz235941) bz239745 (missing alternatives link) was never in any official Fedora beta package, just in my personal builds. Therefore, revert to the official beta package spec file before proceeding. bz238234 (postscript print does not work) is a potential blocker -- it would be bad to release an emacs that can't print. bz235941 (php-mode missing) is a regression. Thanks, Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From Jochen at herr-schmitt.de Wed May 23 14:42:37 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 23 May 2007 16:42:37 +0200 Subject: please tag emacs-22_0_990-2_fc7 to fc7-final In-Reply-To: References: Message-ID: <465452DD.2030302@herr-schmitt.de> Chip Coldwell schrieb: > This build > > reverts all packaging changes since 22.0.95-1 (Resolves: bz239745) > new pretest tarball from FSF (Resolves: bz238234) > restore php-mode (Resolves: bz235941) > Please send this kind of requests to rel-eng at fedoraproject.org Best Regards: Jochen Schmitt From coldwell at redhat.com Wed May 23 14:46:16 2007 From: coldwell at redhat.com (Chip Coldwell) Date: Wed, 23 May 2007 10:46:16 -0400 (EDT) Subject: please tag emacs-22_0_990-2_fc7 to fc7-final In-Reply-To: <465452DD.2030302@herr-schmitt.de> References: <465452DD.2030302@herr-schmitt.de> Message-ID: On Wed, 23 May 2007, Jochen Schmitt wrote: > Chip Coldwell schrieb: > > This build > > > > reverts all packaging changes since 22.0.95-1 (Resolves: bz239745) > > new pretest tarball from FSF (Resolves: bz238234) > > restore php-mode (Resolves: bz235941) > > > Please send this kind of requests to > > rel-eng at fedoraproject.org > > Best Regards: They were cc'd on the original message. Chip -- Charles M. "Chip" Coldwell Senior Software Engineer Red Hat, Inc 978-392-2426 From notting at redhat.com Wed May 23 16:53:26 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 May 2007 12:53:26 -0400 Subject: please tag emacs-22_0_990-2_fc7 to fc7-final In-Reply-To: References: Message-ID: <20070523165326.GC6019@nostromo.devel.redhat.com> Chip Coldwell (coldwell at redhat.com) said: > > This build > > reverts all packaging changes since 22.0.95-1 (Resolves: bz239745) > new pretest tarball from FSF (Resolves: bz238234) > restore php-mode (Resolves: bz235941) > > bz239745 (missing alternatives link) was never in any official Fedora > beta package, just in my personal builds. Therefore, revert to the > official beta package spec file before proceeding. > > bz238234 (postscript print does not work) is a potential blocker -- it > would be bad to release an emacs that can't print. > > bz235941 (php-mode missing) is a regression. +1 Bill From jkeating at redhat.com Wed May 23 17:00:43 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 May 2007 13:00:43 -0400 Subject: [TAGGED] Re: please tag emacs-22_0_990-2_fc7 to fc7-final In-Reply-To: <20070523165326.GC6019@nostromo.devel.redhat.com> References: <20070523165326.GC6019@nostromo.devel.redhat.com> Message-ID: <200705231300.43671.jkeating@redhat.com> On Wednesday 23 May 2007 12:53:26 Bill Nottingham wrote: > > ?reverts all packaging changes since 22.0.95-1 (Resolves: bz239745) > > ?new pretest tarball from FSF (Resolves: bz238234) > > ?restore php-mode (Resolves: bz235941) > > > > bz239745 (missing alternatives link) was never in any official Fedora > > beta package, just in my personal builds. ?Therefore, revert to the > > official beta package spec file before proceeding. > > > > bz238234 (postscript print does not work) is a potential blocker -- it > > would be bad to release an emacs that can't print. > > > > bz235941 (php-mode missing) is a regression. > > +1 Tagged. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Wed May 23 17:07:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 May 2007 13:07:09 -0400 Subject: Branching done ?? In-Reply-To: References: <464DC421.2020903@hhs.nl> <1179500939.3046.9.camel@vader.jdub.homelinux.org> <464DC6DD.8080402@hhs.nl> <20070518181957.GB19544@nostromo.devel.redhat.com> <20070518182125.GC19544@nostromo.devel.redhat.com> <38EAEABE-1ACC-4EB6-8490-28666386F43E@rubenkerkhof.com> <20070522211528.GA25506@nostromo.devel.redhat.com> Message-ID: <20070523170709.GE6019@nostromo.devel.redhat.com> Ruben Kerkhof (ruben at rubenkerkhof.com) said: > > On 22-mei-2007, at 23:15, Bill Nottingham wrote: > > >Ruben Kerkhof (ruben at rubenkerkhof.com) said: > >>Any luck with this? > >>I've got a few (new) packages with a missing F-7 branch as well: > >>perl-IO-AIO, perl-Danga-Socket and perl-Sys-Syscall > > > >When were they added? If they were added after the mass branch, > >it should be done through the 'normal' CVS process that's > >used for FC-6, etc. branches. > > > >Bill > > They were added on the 16th, so AFAIKS before the merge. Branched. Bill From tibbs at math.uh.edu Wed May 23 17:22:33 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 May 2007 12:22:33 -0500 Subject: Summary of the 2007-05-23 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-05-22 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070522 Executive summary: No new guidelines this week. (spot did write up and announce some PHP changes which were previously ratified.) These should be written into the guidelines soon if this hasn't already been done by the time you read this. Issues pending FESCO ratification: * Tweaks to static library packaging guidelines (accepted 7-0): http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges Misc business: * Emacs packaging guidelines; will probably be considered next week: http://fedoraproject.org/wiki/PackagingDrafts/EmacsenAddOns * Guidelines for packages needing users and groups: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups * OCaml guidelines; draft not yet ready for a vote: http://fedoraproject.org/wiki/PackagingDrafts/OCaml - J< From jonathan.underwood at gmail.com Wed May 23 21:25:12 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 23 May 2007 22:25:12 +0100 Subject: How to deal with circular BuildRequires ? Message-ID: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> Hi, Tom Tromey and I are working on packaging bbdb for Emacs (see BZ 226800). However, there is a circular BuildRequires. In order that the Emacs mailreader VM (packaged as emacs-vm) and bbdb integrate properly, we need to have a BuildRequires: emacs-vm-el in the emacs-bbdb package, and we need to have a BuildRequires: emacs-bbdb-el in the emacs-vm package. In other words, both packages require the elisp source of the other to be present at build time. Is there an established way of solving this chicken and egg situation? Thanks, Jonathan From jonathan.underwood at gmail.com Wed May 23 21:38:43 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 23 May 2007 22:38:43 +0100 Subject: How to deal with circular BuildRequires ? In-Reply-To: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> References: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> Message-ID: <645d17210705231438t78e9fbb1td4266325e9dab91c@mail.gmail.com> On 23/05/07, Jonathan Underwood wrote: > Hi, > > Tom Tromey and I are working on packaging bbdb for Emacs (see BZ > 226800). However, there is a circular BuildRequires. In order that the > Emacs mailreader VM (packaged as emacs-vm) and bbdb integrate > properly, we need to have a BuildRequires: emacs-vm-el in the > emacs-bbdb package, and we need to have a BuildRequires: emacs-bbdb-el > in the emacs-vm package. In other words, both packages require the > elisp source of the other to be present at build time. > > Is there an established way of solving this chicken and egg situation? I should add also that building emacs-vm without the bbdb elisp source present will succeed, producing compiled lisp without bbdb functionality and the source el package as well. The same is true for emacs-bbdb. This is only an issue when wanting to enable bbdb functionality in vm. From ajackson at redhat.com Wed May 23 21:44:08 2007 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 23 May 2007 17:44:08 -0400 Subject: How to deal with circular BuildRequires ? In-Reply-To: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> References: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> Message-ID: <1179956648.18583.126.camel@localhost.localdomain> On Wed, 2007-05-23 at 22:25 +0100, Jonathan Underwood wrote: > Hi, > > Tom Tromey and I are working on packaging bbdb for Emacs (see BZ > 226800). However, there is a circular BuildRequires. In order that the > Emacs mailreader VM (packaged as emacs-vm) and bbdb integrate > properly, we need to have a BuildRequires: emacs-vm-el in the > emacs-bbdb package, and we need to have a BuildRequires: emacs-bbdb-el > in the emacs-vm package. In other words, both packages require the > elisp source of the other to be present at build time. > > Is there an established way of solving this chicken and egg situation? Would staging work? Build both, then build bbdb with the e-v-e BR, then rebuild e-v-e with the bbdb BR. Eventual problem for new arch bootstrap, but that's not an actively solved problem anyway. - ajax From jonathan.underwood at gmail.com Wed May 23 21:45:16 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 23 May 2007 22:45:16 +0100 Subject: How to deal with circular BuildRequires ? In-Reply-To: <645d17210705231438t78e9fbb1td4266325e9dab91c@mail.gmail.com> References: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> <645d17210705231438t78e9fbb1td4266325e9dab91c@mail.gmail.com> Message-ID: <645d17210705231445l1ec12907o9605c615d556d9b2@mail.gmail.com> On 23/05/07, Jonathan Underwood wrote: > On 23/05/07, Jonathan Underwood wrote: > > Hi, > > > > Tom Tromey and I are working on packaging bbdb for Emacs (see BZ > > 226800). However, there is a circular BuildRequires. In order that the > > Emacs mailreader VM (packaged as emacs-vm) and bbdb integrate > > properly, we need to have a BuildRequires: emacs-vm-el in the > > emacs-bbdb package, and we need to have a BuildRequires: emacs-bbdb-el > > in the emacs-vm package. In other words, both packages require the > > elisp source of the other to be present at build time. > > > > Is there an established way of solving this chicken and egg situation? > > I should add also that building emacs-vm without the bbdb elisp source > present will succeed, producing compiled lisp without bbdb > functionality and the source el package as well. The same is true for > emacs-bbdb. This is only an issue when wanting to enable bbdb > functionality in vm. And to answer my own mail again, thanks to notting on IRC the solution is now clear to me - build both packages without the circular BuildRequires. One packages exist for both, add the circular BuildRequires and build again. From tgl at redhat.com Wed May 23 21:51:51 2007 From: tgl at redhat.com (Tom Lane) Date: Wed, 23 May 2007 17:51:51 -0400 Subject: How to deal with circular BuildRequires ? In-Reply-To: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> References: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> Message-ID: <24917.1179957111@sss.pgh.pa.us> "Jonathan Underwood" writes: > Tom Tromey and I are working on packaging bbdb for Emacs (see BZ > 226800). However, there is a circular BuildRequires. In order that the > Emacs mailreader VM (packaged as emacs-vm) and bbdb integrate > properly, we need to have a BuildRequires: emacs-vm-el in the > emacs-bbdb package, and we need to have a BuildRequires: emacs-bbdb-el > in the emacs-vm package. In other words, both packages require the > elisp source of the other to be present at build time. > Is there an established way of solving this chicken and egg situation? If no better idea presents itself, you could have a single SRPM generating both RPMs. IOW, merge bbdb into the existing emacs-vm SRPM. Version numbering would be a problem though. regards, tom lane From jonathan.underwood at gmail.com Wed May 23 22:01:48 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 23 May 2007 23:01:48 +0100 Subject: How to deal with circular BuildRequires ? In-Reply-To: <1179956648.18583.126.camel@localhost.localdomain> References: <645d17210705231425i2b66392h92c38cf52ece55aa@mail.gmail.com> <1179956648.18583.126.camel@localhost.localdomain> Message-ID: <645d17210705231501r48532267m90bbeea4813dddc7@mail.gmail.com> On 23/05/07, Adam Jackson wrote: > Would staging work? Build both, then build bbdb with the e-v-e BR, then > rebuild e-v-e with the bbdb BR. > Yup, that's what I'll do, thanks. > Eventual problem for new arch bootstrap, but that's not an actively > solved problem anyway. Yeah, I'll put comments in the spec files for each package loudly pointing out the need to do this bootstrapping when a new arch is introduced. J. From bpepple at fedoraproject.org Thu May 24 00:11:49 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 23 May 2007 20:11:49 -0400 Subject: Plan for tomorrows (20070524) FESCO meeting Message-ID: <1179965509.5783.7.camel@lincoln> Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- proposal to answer the guidelines question -- https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00634.html /topic FESCO-Meeting -- MISC -- F7 Prep /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- MISC -- Policies that need updating for merge? -- http://fedoraproject.org/wiki/PackageMaintainers/Policy /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu May 24 02:28:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 May 2007 22:28:27 -0400 Subject: No more "new" packages to f7-final Message-ID: <200705232228.28260.jkeating@redhat.com> We're in the final stretch of getting f7 gold. As such we'll no longer be taking "new" packages to Fedora 7. They can be issued as updates to Fedora 7 once it ships. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu May 24 03:33:09 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 May 2007 23:33:09 -0400 Subject: ppc64 packages that did not build for dist-fc7 Message-ID: <20070524033309.GA15157@nostromo.devel.redhat.com> As part of the merge, we bootstrapped and imported Extras for ppc64. Not all packages built correctly. Logs of the failures are available at: http://people.redhat.com/notting/ppc64-rebuild/ Bugs have only been filed for some of these at this point. Common failure cases are: - build deps: no ocaml support on ppc64 (being worked on) - build deps: no mono support on ppc64 (needs excludearch) - inability to build shared libraries. This is due to ancient libtool stuff in the package; a patch can be found at: http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=154193 The list of packages: abicheck-1.2-11 airsnort-0.2.7e-11.fc7 anjuta-2.1.0-1.fc7 anjuta-gdl-0.7.3-1.fc7 apollon-1.0.1-7.fc6 aqbanking-2.2.9-1 atlas-3.6.0-11.fc6 autogen-5.8.9-1.fc7 banshee-0.12.1-2.fc7 bigloo-2.9a-3.fc7 blam-1.8.3-3.fc7 boo-0.7.6.2237-12.fc7 brasero-0.5.2-1.fc7 chess-1.0-5.fc7 claws-mail-plugins-2.9.1-1.fc7 clearsilver-0.10.4-3.fc7 compat-libgda-1.2.4-1.fc7 cowbell-0.2.7.1-6.fc6 csmash-0.6.6-14.fc7 csync2-1.33-5.fc7 curry-0.9.10-3.fc6 cyrus-imapd-2.3.8-3.fc7 daap-sharp-0.3.3-4.fc6 darcs-1.0.9-0.1.rc2.fc7 e2tools-0.0.16-5.fc7 eclipse-mylar-2.0-0.1.M2a.1.fc7 ejabberd-1.1.3-1.fc7 em8300-kmod-0.16.2-0.2.6.20_1.3104.fc7.1.rc2 fpc-2.0.4-2.fc6 frozen-bubble-2.1.0-2.fc7 fvwm-2.5.21-4.fc7 gai-pal-0.7-11 gambas-1.0.17-8.fc7 gauche-0.8.10-1.fc7 gauche-gl-0.4.3-3.fc7 gauche-gtk-0.4.1-12.fc7 gdl-0.9-0.pre4.1.fc7 geda-gnetlist-20070216-1.fc7 geda-gschem-20070216-1.fc7 ghdl-0.25-0.89svn.2.fc7 gift-0.11.8.1-6.fc7 gift-gnutella-0.0.11-1.fc7 gift-openft-0.2.1.6-3.fc6 glom-1.4.2-1.fc7 gnome-build-0.1.4-2.fc7 gnome-libs-1.4.2-5.fc7 gnome-python2-gda-2.14.3-1.fc7 gnucash-2.0.5-3.fc7 gnu-smalltalk-2.3.3-5.fc7 gstm-1.2-6.fc7 GtkAda-2.8.0-7.fc7 gtkmozembedmm-1.4.2.cvs20060817-10.fc7 gtk-sharp-1.0.10-12.fc7 gtksourceview-sharp-2.0-25.fc7 gwget-0.98.2-1.fc7 haddock-0.8-1.fc7 happy-1.16-2.fc7 harminv-1.3.1-8.fc6 heartbeat-2.0.8-1.fc7 hevea-1.08-6.fc6 ikvm-0.22-10.fc6 Inventor-2.1.5-26.fc7 ipod-sharp-0.6.3-1.fc7 irssi-0.8.10-7.a.fc7 itpp-3.10.10-1.fc7 jogl-1.0.0-5.7.beta5.fc6 k3d-0.6.5.0-1.fc7 kawa-1.9.0-2.fc7 kerry-0.2.1-2.fc7 ktechlab-0.3.6-2.fc7 lablgl-1.02-9.fc7 lablgtk-2.6.0-7.fc7 lat-1.2.2-2.fc7 libdockapp-0.6.1-2.fc7 libgdamm-1.3.7-4.fc6 libglade-0.17-19.fc6 liblrdf-0.4.0-10.fc6 libpolyxmass-0.9.0-6.fc5 libstroke-0.5.1-14.fc7 libtasn1-0.3.9-1.fc7 Macaulay2-0.9.95-4.fc7 marble-0.3.1-3.fc7 maven2-2.0.4-10jpp.6.fc7 maven-doxia-1.0-0.1.a7.3jpp.3.fc7 maven-jxr-1.0-2jpp.2.fc7 maven-scm-1.0-0.1.b3.2jpp.1.fc7 maven-shared-1.0-4jpp.2.fc7 maven-surefire-1.5.3-2jpp.2.fc7 mediawiki-1.9.2-33.fc7 mlton-20061107-2.fc7 mod_mono-1.2.1-1.fc7 monodevelop-0.13.1-1.fc7 monodoc-1.2.3-1.fc7 mosml-2.01-9.fc7 multisync-0.91.0-1.fc7 nagios-2.7-2.fc7 ncarg-4.4.1-9.fc7 ncview-1.92e-10.fc7 netcdf-perl-1.2.3-2.fc7 nginx-0.5.19-1.fc7 numpy-1.0.1-4.fc7 nx-2.1.0-1.fc6 obexftp-0.22-0.2.pre4 ocaml-3.09.3-1.fc7 ogre-1.2.5-1.fc7 oorexx-3.1.1-1.fc7 openalpp-20060714-3.fc7 openarena-0.6.0-4.fc7 opencv-1.0.0-3.fc7 OpenSceneGraph-1.2-2.fc7 orpie-1.4.3-5.fc6 osgal-20060903-3.fc7 osgcal-0.1.44-4.fc7 plexus-ant-factory-1.0-0.1.a1.2jpp.2.fc7 plexus-appserver-1.0-0.1.a5.3jpp.2.fc7 plexus-bsh-factory-1.0-0.1.a7s.2jpp.2.fc7 plexus-cdc-1.0-0.1.a4.2jpp.2.fc7 plexus-maven-plugin-1.2-2jpp.1.fc7 plexus-runtime-builder-1.0-0.1.a9.2jpp.1.fc7 plexus-xmlrpc-1.0-0.1.b4.3jpp.5.fc7 plplot-5.7.3-2.fc7 polyml-5.0-2.fc7 polyxmass-bin-0.9.3-2.fc6 python-crypto-2.0.1-7 python-matplotlib-0.90.0-3.fc7 q-7.6-2.fc7 qt4-qsa-1.2.2-2.fc7 rekall-2.4.5-5.fc7.3 revelation-0.4.11-2.fc7 R-hdf5-1.6.4-2.fc6 rhm-0.1-3.fc7 rrdtool-1.2.19-2.fc7 R-RScaLAPACK-0.5.1-9.fc7 scipy-0.5.2-2.2.fc7 scrip-1.4-6.fc6 sdcc-2.6.0-10.fc7 SDL_gfx-2.0.13-7.fc6 seq24-0.8.7-6.fc6 ser-0.9.6-10.fc7 snort-2.6.1.3-1.fc7 synce-software-manager-0.9.0-7.fc6 synce-trayicon-0.9.0-8.fc6 tachyon-0.97-4.fc7 tripwire-2.4.1.1-1.fc7 unison-2.13.16-3.fc6 util-vserver-0.30.212-3.fc7 warzone2100-2.0.6-2.fc7 wmacpi-2.2-0.1.a1.fc7 xbase-2.0.0-6.fc6 xbsql-0.11-8.fc6 xca-0.6.1-1.fc7 xmlrpc3-3.0-1jpp.1.fc7 xsp-1.2.1-1.fc7 xsupplicant-1.2.8-1.fc7.1 z88dk-1.6-10.fc6 From orion at cora.nwra.com Thu May 24 05:10:31 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 23 May 2007 23:10:31 -0600 (MDT) Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524033309.GA15157@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> Message-ID: <1479.71.208.204.13.1179983431.squirrel@www.cora.nwra.com> > As part of the merge, we bootstrapped and imported Extras for ppc64. > > Not all packages built correctly. Logs of the failures are available at: > http://people.redhat.com/notting/ppc64-rebuild/ > > plplot-5.7.3-2.fc7 Apparently this is because of a missing gcc-gnat, but I don't see that in the list of failed builds. Missing plplot causes other problems (gdl for one) - Orion From notting at redhat.com Thu May 24 05:16:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 May 2007 01:16:51 -0400 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <1479.71.208.204.13.1179983431.squirrel@www.cora.nwra.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <1479.71.208.204.13.1179983431.squirrel@www.cora.nwra.com> Message-ID: <20070524051651.GA16307@nostromo.devel.redhat.com> orion at cora.nwra.com (orion at cora.nwra.com) said: > > As part of the merge, we bootstrapped and imported Extras for ppc64. > > > > Not all packages built correctly. Logs of the failures are available at: > > http://people.redhat.com/notting/ppc64-rebuild/ > > > > plplot-5.7.3-2.fc7 > > Apparently this is because of a missing gcc-gnat, but I don't see that in > the list of failed builds. Missing plplot causes other problems (gdl for > one) Ada would be one of those things (like ocaml, mono, etc) that doesn't exist at the moment for ppc64. It wasn't in the build list since it was a core package. Bill From orion at cora.nwra.com Thu May 24 05:21:42 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 23 May 2007 23:21:42 -0600 (MDT) Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524051651.GA16307@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <1479.71.208.204.13.1179983431.squirrel@www.cora.nwra.com> <20070524051651.GA16307@nostromo.devel.redhat.com> Message-ID: <1615.71.208.204.13.1179984102.squirrel@www.cora.nwra.com> > > Ada would be one of those things (like ocaml, mono, etc) that doesn't > exist at the moment for ppc64. It wasn't in the build list since it > was a core package. > > Bill Is there a bug for this that I can track? I couldn't find one... - Orion From notting at redhat.com Thu May 24 05:25:16 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 May 2007 01:25:16 -0400 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <1615.71.208.204.13.1179984102.squirrel@www.cora.nwra.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <1479.71.208.204.13.1179983431.squirrel@www.cora.nwra.com> <20070524051651.GA16307@nostromo.devel.redhat.com> <1615.71.208.204.13.1179984102.squirrel@www.cora.nwra.com> Message-ID: <20070524052516.GA16436@nostromo.devel.redhat.com> orion at cora.nwra.com (orion at cora.nwra.com) said: > > Ada would be one of those things (like ocaml, mono, etc) that doesn't > > exist at the moment for ppc64. It wasn't in the build list since it > > was a core package. > > Is there a bug for this that I can track? I couldn't find one... There's http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158458 for ppc; I don't see one for ppc64. Bill From orion at cora.nwra.com Thu May 24 05:47:54 2007 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Wed, 23 May 2007 23:47:54 -0600 (MDT) Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524052516.GA16436@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <1479.71.208.204.13.1179983431.squirrel@www.cora.nwra.com> <20070524051651.GA16307@nostromo.devel.redhat.com> <1615.71.208.204.13.1179984102.squirrel@www.cora.nwra.com> <20070524052516.GA16436@nostromo.devel.redhat.com> Message-ID: <1904.71.208.204.13.1179985674.squirrel@www.cora.nwra.com> > orion at cora.nwra.com (orion at cora.nwra.com) said: >> > Ada would be one of those things (like ocaml, mono, etc) that doesn't >> > exist at the moment for ppc64. It wasn't in the build list since it >> > was a core package. >> >> Is there a bug for this that I can track? I couldn't find one... > > There's http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158458 > for ppc; I don't see one for ppc64. > > Bill I've filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241098 From j.w.r.degoede at hhs.nl Thu May 24 06:37:40 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 24 May 2007 08:37:40 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524033309.GA15157@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> Message-ID: <465532B4.3040601@hhs.nl> Bill Nottingham wrote: > ogre-1.2.5-1.fc7 This failure is caused by this piece of code: /* Find the arch type */ #if defined(__x86_64__) || defined(_M_X64) # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64 #else # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32 #endif Which obviously needs to check for something like __ppc64__ too, can anyone tell me what exactly it needs to check for? Regards, Hans From jakub at redhat.com Thu May 24 07:07:07 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 24 May 2007 03:07:07 -0400 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <465532B4.3040601@hhs.nl> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <465532B4.3040601@hhs.nl> Message-ID: <20070524070707.GW4033@devserv.devel.redhat.com> On Thu, May 24, 2007 at 08:37:40AM +0200, Hans de Goede wrote: > Bill Nottingham wrote: > >ogre-1.2.5-1.fc7 > > This failure is caused by this piece of code: > > /* Find the arch type */ > #if defined(__x86_64__) || defined(_M_X64) > # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64 > #else > # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32 > #endif > > Which obviously needs to check for something like __ppc64__ too, can anyone > tell me what exactly it needs to check for? If it wants to check for LP64 architecture, then GCC 3.4 and later defines _LP64 and __LP64__ macros on these arches. Or you can #include and check LONG_MAX etc. Jakub From pertusus at free.fr Thu May 24 08:21:26 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 May 2007 10:21:26 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524033309.GA15157@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> Message-ID: <20070524082125.GA2837@free.fr> On Wed, May 23, 2007 at 11:33:09PM -0400, Bill Nottingham wrote: > As part of the merge, we bootstrapped and imported Extras for ppc64. > libdockapp-0.6.1-2.fc7 I have fixed libdockapp, it was the libtool issue. > wmacpi-2.2-0.1.a1.fc7 Was broken because of missing libdockapp. Will it be rebuilt automatically? -- Pat From j.w.r.degoede at hhs.nl Thu May 24 09:00:49 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 24 May 2007 11:00:49 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524070707.GW4033@devserv.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <465532B4.3040601@hhs.nl> <20070524070707.GW4033@devserv.devel.redhat.com> Message-ID: <46555441.3080905@hhs.nl> Jakub Jelinek wrote: > On Thu, May 24, 2007 at 08:37:40AM +0200, Hans de Goede wrote: >> Bill Nottingham wrote: >>> ogre-1.2.5-1.fc7 >> This failure is caused by this piece of code: >> >> /* Find the arch type */ >> #if defined(__x86_64__) || defined(_M_X64) >> # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_64 >> #else >> # define OGRE_ARCH_TYPE OGRE_ARCHITECTURE_32 >> #endif >> >> Which obviously needs to check for something like __ppc64__ too, can anyone >> tell me what exactly it needs to check for? > > If it wants to check for LP64 architecture, then GCC 3.4 and later > defines _LP64 and __LP64__ macros on these arches. > Or you can #include and check LONG_MAX etc. > __LP64__ will work nicely, although what they are actually trying to check is wether or not size_t is 64 bit. Regards, Hans From limb at jcomserv.net Thu May 24 11:53:10 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 24 May 2007 06:53:10 -0500 (CDT) Subject: No more "new" packages to f7-final In-Reply-To: <200705232228.28260.jkeating@redhat.com> References: <200705232228.28260.jkeating@redhat.com> Message-ID: <4096.65.192.24.190.1180007590.squirrel@mail.jcomserv.net> Will that affect the processing of CVSAdmin requests, or is that just a function of F7 GA being days away? I wasn't sure, since I've had a few go through and some not and I just wanted to make sure it was a wetware bandwidth issue* and not a technical issue. :) > We're in the final stretch of getting f7 gold. As such we'll no longer be > taking "new" packages to Fedora 7. They can be issued as updates to > Fedora 7 > once it ships. *Which, if the case, I am more than sympathetic to. > -- > Jesse Keating > Release Engineer: Fedora > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From pertusus at free.fr Thu May 24 12:05:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 May 2007 14:05:30 +0200 Subject: [SPAM] Re: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1179802735.5161.60.camel@localhost.localdomain> References: <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <1179362111.2746.311.camel@localhost.localdomain> <20070520224451.GB11171@free.fr> <1179802735.5161.60.camel@localhost.localdomain> Message-ID: <20070524120530.GA10625@free.fr> On Mon, May 21, 2007 at 07:58:55PM -0700, Toshio Kuratomi wrote: > > guideline and it was implicitly ok to avoid some changelog entries as > > the reverse seems so unnatural and bureaucratic to me. Moreover I have > > seen a lot of other packagers doing that while reading the commit > > messages without anybody complaining, so I thought it was ok, I stand > > corrected. > > > We could be talking about different things... it's hard to tell from > looking at your changelog :-) > > Every build must have a new changelog entry. Every commit does not. So > when I see this changelog: Ok, I agree if you mean every succesfull build. > * Mon May 14 2007 Patrice Dumas 2006-10.1 > - packlib/{ffread,hbook} test segfaults on ppc64 > > * Sun May 13 2007 Patrice Dumas 2006-9 > - add a compat prefix when built with g77 > - new debian patcheset > > It's fine if 2006-10 was never built. You should have had another entry > if 2006-10 was committed but not built. Didn't you said the reverse above? > Not quite. If you have a package which provides libraries and utilities > it can very easily be linking against static versions of the library > instead of the dynamic versions without pulling in a -static subpackage. Ok, but hopefully the maintainers knowwhat they are doing. And that case isn't that bad since the libraries and the utilities should be released together. > But you have failed to even do that. Phrase your letter as data if you Not failed, but it seemed to be pointless until approval was also needed. I'l try to do a proposal regarding packaging numerical static libs and submit examples by that week-end. > I'm not going to ask to change the guidelines WRT linking to static > libraries. (You'll still have to ask FESCo if you want to link to a > static libary). I agree with that. > I'm not going to ask for a special case exception for numerical > libraries. I'll try to come with something this week-end. > These are significant changes from the current guidelines and they might > not be approved by the Packaging Committee in which case your packaging > will still be out of compliance and someone could open bugs against your > packages. That's fine with me since I think that no one will complain. -- Pat From pertusus at free.fr Thu May 24 12:20:43 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 May 2007 14:20:43 +0200 Subject: [SPAM] Re: Plan for tomorrows (20070524) FESCO meeting In-Reply-To: <1179965509.5783.7.camel@lincoln> References: <1179965509.5783.7.camel@lincoln> Message-ID: <20070524122043.GB10625@free.fr> On Wed, May 23, 2007 at 08:11:49PM -0400, Brian Pepple wrote: > > /topic FESCo meeting -- Free discussion around Fedora I'd like to ask FESCO to acknowledge or criticise 2 deviations from the guideline rules for the cernlib * paw is linked statically against the cern libraries. Otherwise it fails on 64 bit platforms * I ship the static libs in the -devel package. In general I think it is bad, but in the case of the cernlib there are 2 arguments in favor of doing that: - on 64 bit platforms linking dynamically results in failures (like in the paw case) - the script used to drive the link against the cern libraries link statically against those libs (but dynamically against other libs). This is linked with the above issue, of course, and I also think that the cernlib users are waiting for static libs rather than shared ones because that's the only libs upstream propose. Having shared libs has been added by debian (and a recent upstream release didn't include this change). It may also help solve issues with programs portability linked with the shift from g77 to gfortran. More information on http://people.debian.org/~kmccarty/cernlib/faq.html#33 -- Pat From tcallawa at redhat.com Thu May 24 12:50:41 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 May 2007 07:50:41 -0500 Subject: [SPAM] Re: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <20070524120530.GA10625@free.fr> References: <4649ED35.9030607@leemhuis.info> <1179258710.20155.23.camel@localhost.localdomain> <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <1179362111.2746.311.camel@localhost.localdomain> <20070520224451.GB11171@free.fr> <1179802735.5161.60.camel@localhost.localdomain> <20070524120530.GA10625@free.fr> Message-ID: <1180011041.6254.359.camel@localhost.localdomain> On Thu, 2007-05-24 at 14:05 +0200, Patrice Dumas wrote: > > These are significant changes from the current guidelines and they > might > > not be approved by the Packaging Committee in which case your > packaging > > will still be out of compliance and someone could open bugs against > your > > packages. > > That's fine with me since I think that no one will complain. BTW, we did approve these guidelines, and they're up for FESCO ratification today. ~spot From pertusus at free.fr Thu May 24 13:12:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 May 2007 15:12:51 +0200 Subject: [SPAM] Re: [SPAM] Re: Deep Freeze coming for Fedora 7 (and cvs branching coming too) In-Reply-To: <1180011041.6254.359.camel@localhost.localdomain> References: <20070515203617.GB2828@free.fr> <464A20FA.2090101@fedoraproject.org> <20070515211134.GF2828@free.fr> <1179272593.2746.89.camel@localhost.localdomain> <20070516200454.GB2890@free.fr> <1179362111.2746.311.camel@localhost.localdomain> <20070520224451.GB11171@free.fr> <1179802735.5161.60.camel@localhost.localdomain> <20070524120530.GA10625@free.fr> <1180011041.6254.359.camel@localhost.localdomain> Message-ID: <20070524131251.GF10625@free.fr> On Thu, May 24, 2007 at 07:50:41AM -0500, Tom spot Callaway wrote: > > BTW, we did approve these guidelines, and they're up for FESCO > ratification today. Indeed, but FESCO may still not ratify them (although it would be a bit surprising). -- Pat From notting at redhat.com Thu May 24 18:01:38 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 May 2007 14:01:38 -0400 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524082125.GA2837@free.fr> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <20070524082125.GA2837@free.fr> Message-ID: <20070524180138.GB21794@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > On Wed, May 23, 2007 at 11:33:09PM -0400, Bill Nottingham wrote: > > As part of the merge, we bootstrapped and imported Extras for ppc64. > > > libdockapp-0.6.1-2.fc7 > > I have fixed libdockapp, it was the libtool issue. > > > wmacpi-2.2-0.1.a1.fc7 > > Was broken because of missing libdockapp. Will it be rebuilt > automatically? At this point,such rebuilds would essentially be retroactively changing the frozen Fedora 7 tree; so, no. Bill From pertusus at free.fr Thu May 24 17:57:20 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 May 2007 19:57:20 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524180138.GB21794@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <20070524082125.GA2837@free.fr> <20070524180138.GB21794@nostromo.devel.redhat.com> Message-ID: <20070524175720.GC12227@free.fr> On Thu, May 24, 2007 at 02:01:38PM -0400, Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > > On Wed, May 23, 2007 at 11:33:09PM -0400, Bill Nottingham wrote: > > > As part of the merge, we bootstrapped and imported Extras for ppc64. > > > > > libdockapp-0.6.1-2.fc7 > > > > I have fixed libdockapp, it was the libtool issue. > > > > > wmacpi-2.2-0.1.a1.fc7 > > > > Was broken because of missing libdockapp. Will it be rebuilt > > automatically? > > At this point,such rebuilds would essentially be retroactively changing > the frozen Fedora 7 tree; so, no. So a rebuild of wmacpi has to be done by the maintainer? And should I ask rel-eng for libdockapp on ppc64 or is it added when it is built? Or is it too late? -- Pat From notting at redhat.com Thu May 24 18:13:45 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 May 2007 14:13:45 -0400 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524175720.GC12227@free.fr> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <20070524082125.GA2837@free.fr> <20070524180138.GB21794@nostromo.devel.redhat.com> <20070524175720.GC12227@free.fr> Message-ID: <20070524181344.GC21794@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > > At this point,such rebuilds would essentially be retroactively changing > > the frozen Fedora 7 tree; so, no. > > So a rebuild of wmacpi has to be done by the maintainer? Yes. > And should I ask rel-eng for libdockapp on ppc64 or is it added when it > is built? Or is it too late? If the thing you're building is a buildrequirement of something else, send mail via the normal rel-eng@ process, and we'll try and get it in Fedora 7 (no guarantees, depending on release timing.) If it's not a build req, wait for an update, or Fedora 8 (as most leaf nodes won't be shipped in the ppc tree.) Bill From Jochen at herr-schmitt.de Thu May 24 19:13:24 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 24 May 2007 21:13:24 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524033309.GA15157@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> Message-ID: <0ML31I-1HrIoK1npC-000428@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 23 May 2007 23:33:09 -0400, you wrote: >gnu-smalltalk-2.3.3-5.fc7 I not understanding the problem becouse on the buildsys it look nice. http://koji.fedoraproject.org/koji/buildinfo?buildID=3845 Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) Charset: us-ascii wj8DBQFGVePvT2AHK6txfgwRAjqAAKDJh4ELn9kiPD2nX9rQqQX3iaiR6wCgneIK VzJTW0/bQlzDAB57Qnlwhyg= =xUIW -----END PGP SIGNATURE----- From bugs.michael at gmx.net Thu May 24 20:20:53 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 24 May 2007 22:20:53 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <0ML31I-1HrIoK1npC-000428@mrelayeu.kundenserver.de> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <0ML31I-1HrIoK1npC-000428@mrelayeu.kundenserver.de> Message-ID: <20070524222053.5d01c1ee.bugs.michael@gmx.net> On Thu, 24 May 2007 21:13:24 +0200, Jochen Schmitt wrote: > >gnu-smalltalk-2.3.3-5.fc7 > > I not understanding the problem becouse on the buildsys it look > nice. > > http://koji.fedoraproject.org/koji/buildinfo?buildID=3845 Look here for the ppc64 (!) build logs: http://people.redhat.com/notting/ppc64-rebuild/gnu-smalltalk-2.3.3-5.fc7/ From Jochen at herr-schmitt.de Thu May 24 20:28:38 2007 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 24 May 2007 22:28:38 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524222053.5d01c1ee.bugs.michael@gmx.net> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <0ML31I-1HrIoK1npC-000428@mrelayeu.kundenserver.de> <20070524222053.5d01c1ee.bugs.michael@gmx.net> Message-ID: <4655F576.6010603@herr-schmitt.de> Michael Schwendt schrieb: > On Thu, 24 May 2007 21:13:24 +0200, Jochen Schmitt wrote: > > Look here for the ppc64 (!) build logs: > > http://people.redhat.com/notting/ppc64-rebuild/gnu-smalltalk-2.3.3-5.fc7/ > > The only thing, I have found in the log file was the line cpio: snprintfv/snprintfv/stream.in: No such file or directory 4615 blocks + /usr/lib/rpm/check-buildroot Binary file /var/tmp/gnu-smalltalk-2.3.3-root-mockbuild/usr/lib64/gnu-smalltalk/gst.im matches Found '/var/tmp/gnu-smalltalk-2.3.3-root-mockbuild' in installed files; aborting error: Bad exit status from /var/tmp/rpm-tmp.18050 (%install) Unfortunately, I have no idea what was going wrong. It will be nice, if someone have a hint. Best Regards: Jochen Schmitt From orion at cora.nwra.com Thu May 24 20:58:14 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 24 May 2007 14:58:14 -0600 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <4655F576.6010603@herr-schmitt.de> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <0ML31I-1HrIoK1npC-000428@mrelayeu.kundenserver.de> <20070524222053.5d01c1ee.bugs.michael@gmx.net> <4655F576.6010603@herr-schmitt.de> Message-ID: <4655FC66.1010502@cora.nwra.com> Jochen Schmitt wrote: > The only thing, I have found in the log file was the line > > cpio: snprintfv/snprintfv/stream.in: No such file or directory > 4615 blocks > + /usr/lib/rpm/check-buildroot > Binary file > /var/tmp/gnu-smalltalk-2.3.3-root-mockbuild/usr/lib64/gnu-smalltalk/gst.im > matches > Found '/var/tmp/gnu-smalltalk-2.3.3-root-mockbuild' in installed files; > aborting > error: Bad exit status from /var/tmp/rpm-tmp.18050 (%install) > > Unfortunately, I have no idea what was going wrong. > > It will be nice, if someone have a hint. > One of the installed files contains the string "/var/tmp/gnu-smalltalk-2.3.3-root-mockbuild" - i.e. the mock build directory. This is bad because no installed files should reference the build directory path. This is odd though because I wouldn't expect this to be a ppc64 only issue. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From bugs.michael at gmx.net Thu May 24 21:28:18 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 24 May 2007 23:28:18 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <4655F576.6010603@herr-schmitt.de> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <0ML31I-1HrIoK1npC-000428@mrelayeu.kundenserver.de> <20070524222053.5d01c1ee.bugs.michael@gmx.net> <4655F576.6010603@herr-schmitt.de> Message-ID: <20070524232818.52ae5e9d.bugs.michael@gmx.net> On Thu, 24 May 2007 22:28:38 +0200, Jochen Schmitt wrote: > > http://people.redhat.com/notting/ppc64-rebuild/gnu-smalltalk-2.3.3-5.fc7/ > > > > > > The only thing, I have found in the log file was the line > > cpio: snprintfv/snprintfv/stream.in: No such file or directory > 4615 blocks That is just part of the debuginfo package generation. Look further below where the following script is run to examine the buildroot contents: > + /usr/lib/rpm/check-buildroot > Binary file /var/tmp/gnu-smalltalk-2.3.3-root-mockbuild/usr/lib64/gnu-smalltalk/gst.im matches > Found '/var/tmp/gnu-smalltalk-2.3.3-root-mockbuild' in installed files; aborting It seems, check-buildroot is not enabled consistently for all build targets. But where it is enabled and reports an error, the problem ought to be examined, because buildroot paths must not enter files in the package. From notting at redhat.com Fri May 25 02:29:25 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 May 2007 22:29:25 -0400 Subject: final kernel biult Message-ID: <20070525022925.GA29021@nostromo.devel.redhat.com> kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, barring any late-breaking issues. If you have kmod packages that need built, you should build them now. Bill From jkeating at redhat.com Fri May 25 02:39:25 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 May 2007 22:39:25 -0400 Subject: final kernel biult In-Reply-To: <20070525022925.GA29021@nostromo.devel.redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> Message-ID: <200705242239.26185.jkeating@redhat.com> On Thursday 24 May 2007 22:29:25 Bill Nottingham wrote: > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > barring any late-breaking issues. If you have kmod packages that > need built, you should build them now. ngggh.. I don't think we can take in any more package tags without slipping the release. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri May 25 02:54:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 May 2007 22:54:11 -0400 Subject: final kernel biult In-Reply-To: <200705242239.26185.jkeating@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <200705242239.26185.jkeating@redhat.com> Message-ID: <20070525025411.GB29021@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Thursday 24 May 2007 22:29:25 Bill Nottingham wrote: > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > barring any late-breaking issues. If you have kmod packages that > > need built, you should build them now. > > ngggh.. I don't think we can take in any more package tags without slipping > the release. Well, to be blunt, we were asked to notify people over a week ago, and we said that we should have time to allow for it. Bill From jkeating at redhat.com Fri May 25 03:00:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 May 2007 23:00:19 -0400 Subject: final kernel biult In-Reply-To: <20070525025411.GB29021@nostromo.devel.redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <200705242239.26185.jkeating@redhat.com> <20070525025411.GB29021@nostromo.devel.redhat.com> Message-ID: <200705242300.19666.jkeating@redhat.com> On Thursday 24 May 2007 22:54:11 Bill Nottingham wrote: > Well, to be blunt, we were asked to notify people over a week ago, and we > said that we should have time to allow for it. I know it sucks, but we didn't know until this afternoon that this was going to be the final kernel. There is one waiting in the wings if we have to slip for any reason. Without denying any kernel update for a full day or more before we spin the final tree I don't see a way around this. I don't know if I can justify slipping the Fedora 7 release to pick up some kernel module builds that are going to be obsoleted by 0-day kernel updates anyway. Kernel modules aren't on the media or LiveCD anyway. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri May 25 06:48:47 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 25 May 2007 09:48:47 +0300 Subject: final kernel biult In-Reply-To: <200705242300.19666.jkeating@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <20070525025411.GB29021@nostromo.devel.redhat.com> <200705242300.19666.jkeating@redhat.com> Message-ID: <200705250948.48001.ville.skytta@iki.fi> On Friday 25 May 2007, Jesse Keating wrote: > On Thursday 24 May 2007 22:54:11 Bill Nottingham wrote: > > Well, to be blunt, we were asked to notify people over a week ago, and we > > said that we should have time to allow for it. > > I know it sucks, but we didn't know until this afternoon that this was > going to be the final kernel. There is one waiting in the wings if we have > to slip for any reason. Without denying any kernel update for a full day > or more before we spin the final tree I don't see a way around this. I > don't know if I can justify slipping the Fedora 7 release to pick up some > kernel module builds that are going to be obsoleted by 0-day kernel updates > anyway. Kernel modules aren't on the media or LiveCD anyway. em8300-kmod 0.16.2-6.2.6.21_1.3194.fc7 has been ready since yesterday: http://koji.fedoraproject.org/koji/buildinfo?buildID=7168 If it's too late to get in f7-final, please tag it so that it is included in the first batch of F7 updates. From giallu at gmail.com Fri May 25 14:32:50 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 25 May 2007 16:32:50 +0200 Subject: final kernel biult In-Reply-To: <200705242300.19666.jkeating@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <200705242239.26185.jkeating@redhat.com> <20070525025411.GB29021@nostromo.devel.redhat.com> <200705242300.19666.jkeating@redhat.com> Message-ID: On 5/25/07, Jesse Keating wrote: > I don't know if > I can justify slipping the Fedora 7 release to pick up some kernel module > builds that are going to be obsoleted by 0-day kernel updates anyway. Kernel > modules aren't on the media or LiveCD anyway. That's completely agreeable. I don't think anyone will loose sleep for the missing sysprof-kmod... Anyway. Here is the build: http://koji.fedoraproject.org/koji/buildinfo?buildID=7256 From bnocera at redhat.com Fri May 25 14:35:17 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 25 May 2007 15:35:17 +0100 Subject: final kernel biult In-Reply-To: <20070525022925.GA29021@nostromo.devel.redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> Message-ID: <1180103717.14752.41.camel@cookie.hadess.net> On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > barring any late-breaking issues. If you have kmod packages that > need built, you should build them now. For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot on my laptop. From bbbush.yuan at gmail.com Fri May 25 15:32:22 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Fri, 25 May 2007 23:32:22 +0800 Subject: final kernel biult In-Reply-To: <1180103717.14752.41.camel@cookie.hadess.net> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> Message-ID: <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> 2007/5/25, Bastien Nocera : > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > barring any late-breaking issues. If you have kmod packages that > > need built, you should build them now. > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > on my laptop. > meeee too. Dell e1405(640m) don't boot with 3194 or 3201. -- bbbush ^_^ From katzj at redhat.com Fri May 25 15:54:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 25 May 2007 11:54:34 -0400 Subject: final kernel biult In-Reply-To: <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> Message-ID: <1180108474.8492.6.camel@aglarond.local> On Fri, 2007-05-25 at 23:32 +0800, Yuan Yijun wrote: > 2007/5/25, Bastien Nocera : > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > barring any late-breaking issues. If you have kmod packages that > > > need built, you should build them now. > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > on my laptop. > > > > meeee too. Dell e1405(640m) don't boot with 3194 or 3201. Does maxcpus=1 help? Jeremy From Axel.Thimm at ATrpms.net Fri May 25 15:59:46 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 25 May 2007 17:59:46 +0200 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <1180103717.14752.41.camel@cookie.hadess.net> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> Message-ID: <20070525155946.GC13947@neu.nirvana> On Fri, May 25, 2007 at 03:35:17PM +0100, Bastien Nocera wrote: > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > barring any late-breaking issues. If you have kmod packages that > > need built, you should build them now. > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > on my laptop. FWIW 3194 isn't even on download.fedora.redhat.com to test it: -rw-r--r-- 46912778 2007/05/23 17:14:37 kernel-2.6.21-1.3190.fc7.src.rpm -rw-r--r-- 47895419 2007/05/23 17:17:06 kernel-xen-2.6-2.6.20-2925.9.fc7.src.rpm -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eric.tanguy at univ-nantes.fr Fri May 25 16:06:14 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 25 May 2007 18:06:14 +0200 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <20070525155946.GC13947@neu.nirvana> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <20070525155946.GC13947@neu.nirvana> Message-ID: <1180109174.5140.0.camel@bureau.maison> Le vendredi 25 mai 2007 ? 17:59 +0200, Axel Thimm a ?crit : > On Fri, May 25, 2007 at 03:35:17PM +0100, Bastien Nocera wrote: > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > barring any late-breaking issues. If you have kmod packages that > > > need built, you should build them now. > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > on my laptop. > > FWIW 3194 isn't even on download.fedora.redhat.com to test it: > > -rw-r--r-- 46912778 2007/05/23 17:14:37 kernel-2.6.21-1.3190.fc7.src.rpm > -rw-r--r-- 47895419 2007/05/23 17:17:06 kernel-xen-2.6-2.6.20-2925.9.fc7.src.rpm > -- http://koji.fedoraproject.org/koji/packageinfo?packageID=8 Eric From caillon at redhat.com Fri May 25 16:03:52 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 25 May 2007 12:03:52 -0400 Subject: Where's 3194? In-Reply-To: <20070525155946.GC13947@neu.nirvana> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <20070525155946.GC13947@neu.nirvana> Message-ID: <465708E8.8040509@redhat.com> Axel Thimm wrote: > On Fri, May 25, 2007 at 03:35:17PM +0100, Bastien Nocera wrote: >> On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: >> > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, >> > barring any late-breaking issues. If you have kmod packages that >> > need built, you should build them now. >> >> For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot >> on my laptop. > > FWIW 3194 isn't even on download.fedora.redhat.com to test it: You can almost always find the latest kernels in davej's repo: http://people.redhat.com/davej/kernels/Fedora/fc7/ From Axel.Thimm at ATrpms.net Fri May 25 16:14:32 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 25 May 2007 18:14:32 +0200 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <1180109174.5140.0.camel@bureau.maison> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <20070525155946.GC13947@neu.nirvana> <1180109174.5140.0.camel@bureau.maison> Message-ID: <20070525161432.GE13947@neu.nirvana> On Fri, May 25, 2007 at 06:06:14PM +0200, Tanguy Eric wrote: > Le vendredi 25 mai 2007 ? 17:59 +0200, Axel Thimm a ?crit : > > On Fri, May 25, 2007 at 03:35:17PM +0100, Bastien Nocera wrote: > > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > > barring any late-breaking issues. If you have kmod packages that > > > > need built, you should build them now. > > > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > > on my laptop. > > > > FWIW 3194 isn't even on download.fedora.redhat.com to test it: > > > > -rw-r--r-- 46912778 2007/05/23 17:14:37 kernel-2.6.21-1.3190.fc7.src.rpm > > -rw-r--r-- 47895419 2007/05/23 17:17:06 kernel-xen-2.6-2.6.20-2925.9.fc7.src.rpm > > -- > http://koji.fedoraproject.org/koji/packageinfo?packageID=8 Thanks. Out of curiosity - with koji/mash and all the new toys hwo long does it take for something to hit rawhide? 3190 was just added and it's 3 days old. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eric.tanguy at univ-nantes.fr Fri May 25 16:22:57 2007 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Fri, 25 May 2007 18:22:57 +0200 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <20070525161432.GE13947@neu.nirvana> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <20070525155946.GC13947@neu.nirvana> <1180109174.5140.0.camel@bureau.maison> <20070525161432.GE13947@neu.nirvana> Message-ID: <1180110177.5140.2.camel@bureau.maison> Le vendredi 25 mai 2007 ? 18:14 +0200, Axel Thimm a ?crit : > On Fri, May 25, 2007 at 06:06:14PM +0200, Tanguy Eric wrote: > > Le vendredi 25 mai 2007 ? 17:59 +0200, Axel Thimm a ?crit : > > > On Fri, May 25, 2007 at 03:35:17PM +0100, Bastien Nocera wrote: > > > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > > > barring any late-breaking issues. If you have kmod packages that > > > > > need built, you should build them now. > > > > > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > > > on my laptop. > > > > > > FWIW 3194 isn't even on download.fedora.redhat.com to test it: > > > > > > -rw-r--r-- 46912778 2007/05/23 17:14:37 kernel-2.6.21-1.3190.fc7.src.rpm > > > -rw-r--r-- 47895419 2007/05/23 17:17:06 kernel-xen-2.6-2.6.20-2925.9.fc7.src.rpm > > > -- > > http://koji.fedoraproject.org/koji/packageinfo?packageID=8 > > Thanks. Out of curiosity - with koji/mash and all the new toys hwo > long does it take for something to hit rawhide? 3190 was just added > and it's 3 days old. I think the push is done manually. Eric From jkeating at redhat.com Fri May 25 16:24:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 May 2007 12:24:53 -0400 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <20070525161432.GE13947@neu.nirvana> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180109174.5140.0.camel@bureau.maison> <20070525161432.GE13947@neu.nirvana> Message-ID: <200705251224.54084.jkeating@redhat.com> On Friday 25 May 2007 12:14:32 Axel Thimm wrote: > Thanks. Out of curiosity - with koji/mash and all the new toys hwo > long does it take for something to hit rawhide? 3190 was just added > and it's 3 days old. Rawhide is still a nightly compose. 3914 was in the compose that happened last night. If mirrors haven't picked it up yet that's something different. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bnocera at redhat.com Fri May 25 16:23:59 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 25 May 2007 17:23:59 +0100 Subject: final kernel biult In-Reply-To: <1180108474.8492.6.camel@aglarond.local> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <1180108474.8492.6.camel@aglarond.local> Message-ID: <1180110239.5019.3.camel@cookie.hadess.net> On Fri, 2007-05-25 at 11:54 -0400, Jeremy Katz wrote: > On Fri, 2007-05-25 at 23:32 +0800, Yuan Yijun wrote: > > 2007/5/25, Bastien Nocera : > > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > > barring any late-breaking issues. If you have kmod packages that > > > > need built, you should build them now. > > > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > > on my laptop. > > > > > > > meeee too. Dell e1405(640m) don't boot with 3194 or 3201. > > Does maxcpus=1 hel Yep, "fixes" it for me. From davej at redhat.com Fri May 25 16:31:04 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 25 May 2007 12:31:04 -0400 Subject: final kernel biult In-Reply-To: <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> Message-ID: <20070525163104.GA26902@redhat.com> On Fri, May 25, 2007 at 11:32:22PM +0800, Yuan Yijun wrote: > 2007/5/25, Bastien Nocera : > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > barring any late-breaking issues. If you have kmod packages that > > > need built, you should build them now. > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > on my laptop. > > > > meeee too. Dell e1405(640m) don't boot with 3194 or 3201. What was the last one that did boot ? Dave -- http://www.codemonkey.org.uk From Axel.Thimm at ATrpms.net Fri May 25 16:38:57 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 25 May 2007 18:38:57 +0200 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <200705251224.54084.jkeating@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180109174.5140.0.camel@bureau.maison> <20070525161432.GE13947@neu.nirvana> <200705251224.54084.jkeating@redhat.com> Message-ID: <20070525163857.GF13947@neu.nirvana> On Fri, May 25, 2007 at 12:24:53PM -0400, Jesse Keating wrote: > On Friday 25 May 2007 12:14:32 Axel Thimm wrote: > > Thanks. Out of curiosity - with koji/mash and all the new toys hwo > > long does it take for something to hit rawhide? 3190 was just added > > and it's 3 days old. > > Rawhide is still a nightly compose. 3914 was in the compose that happened > last night. If mirrors haven't picked it up yet that's something different. I was quoting the master mirrors. But alas, looking at rsync://download.fedora.redhat.com/ now 3190 was just replaced by 3194. Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri May 25 16:41:10 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 25 May 2007 18:41:10 +0200 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <20070525163857.GF13947@neu.nirvana> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180109174.5140.0.camel@bureau.maison> <20070525161432.GE13947@neu.nirvana> <200705251224.54084.jkeating@redhat.com> <20070525163857.GF13947@neu.nirvana> Message-ID: <20070525164110.GG13947@neu.nirvana> On Fri, May 25, 2007 at 06:38:57PM +0200, Axel Thimm wrote: > On Fri, May 25, 2007 at 12:24:53PM -0400, Jesse Keating wrote: > > On Friday 25 May 2007 12:14:32 Axel Thimm wrote: > > > Thanks. Out of curiosity - with koji/mash and all the new toys hwo > > > long does it take for something to hit rawhide? 3190 was just added > > > and it's 3 days old. > > > > Rawhide is still a nightly compose. 3914 was in the compose that happened > > last night. If mirrors haven't picked it up yet that's something different. > > I was quoting the master mirrors. > > But alas, looking at rsync://download.fedora.redhat.com/ now 3190 was > just replaced by 3194. Thanks! BTW, just in case something is busted in the nightly composes: Until a couple of hours ago the kernel in rawhide was 3189 while there was a three days old 3190 successful build in koji. So at least for the kernel there were no nightly composes for three nights. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri May 25 16:51:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 May 2007 12:51:48 -0400 Subject: Where's 3194? (was: final kernel biult) In-Reply-To: <20070525164110.GG13947@neu.nirvana> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <20070525163857.GF13947@neu.nirvana> <20070525164110.GG13947@neu.nirvana> Message-ID: <200705251251.48421.jkeating@redhat.com> On Friday 25 May 2007 12:41:10 Axel Thimm wrote: > BTW, just in case something is busted in the nightly composes: Until a > couple of hours ago the kernel in rawhide was 3189 while there was a > three days old 3190 successful build in koji. So at least for the > kernel there were no nightly composes for three nights. The mirrors were having a hard time catching up to all the package signing and other network related fun, so while the compose happened, the master mirrors just may not have gotten caught up. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri May 25 17:22:06 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 25 May 2007 12:22:06 -0500 Subject: final kernel biult In-Reply-To: <20070525163104.GA26902@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> Message-ID: <46571B3E.7070208@math.unl.edu> Dave Jones wrote: > On Fri, May 25, 2007 at 11:32:22PM +0800, Yuan Yijun wrote: > > 2007/5/25, Bastien Nocera : > > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > > barring any late-breaking issues. If you have kmod packages that > > > > need built, you should build them now. > > > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > > on my laptop. > > > > > > > meeee too. Dell e1405(640m) don't boot with 3194 or 3201. > > What was the last one that did boot ? for me, 3168. maxcpus=1 works for later later kernels (3194, 3201) For posterity, see also: http://bugzilla.redhat.com/241249 -- Rex From davej at redhat.com Fri May 25 20:07:54 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 25 May 2007 16:07:54 -0400 Subject: final kernel biult In-Reply-To: <46571B3E.7070208@math.unl.edu> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> Message-ID: <20070525200754.GA10698@redhat.com> On Fri, May 25, 2007 at 12:22:06PM -0500, Rex Dieter wrote: > Dave Jones wrote: > > On Fri, May 25, 2007 at 11:32:22PM +0800, Yuan Yijun wrote: > > > 2007/5/25, Bastien Nocera : > > > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > > > barring any late-breaking issues. If you have kmod packages that > > > > > need built, you should build them now. > > > > > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > > > on my laptop. > > > > > > > > > > meeee too. Dell e1405(640m) don't boot with 3194 or 3201. > > > > What was the last one that did boot ? > > for me, 3168. > maxcpus=1 works for later later kernels (3194, 3201) > > For posterity, see also: > http://bugzilla.redhat.com/241249 Trying to spot a pattern here is hard. Because so far, it seems to be all Dell users, but not all Dell core-duo laptops seem to be affected. My precision M65 for instance is fine. Looking at the diffs between the kernels, the only Dell specific stuff shouldn't affect the various models seeing problems. (They key off the DMI data) Dave -- http://www.codemonkey.org.uk From pertusus at free.fr Fri May 25 20:02:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 May 2007 22:02:38 +0200 Subject: Plan for tomorrows (20070524) FESCO meeting In-Reply-To: <1179965509.5783.7.camel@lincoln> References: <1179965509.5783.7.camel@lincoln> Message-ID: <20070525200238.GC2902@free.fr> On Wed, May 23, 2007 at 08:11:49PM -0400, Brian Pepple wrote: > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > in #fedora-meeting on irc.freenode.org: I'd like to have FESCO advice on linking ipsvd statically against dietlibc. It is Enrico choice on the ipsvd submission https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579 There has been a whole thread: https://www.redhat.com/archives/fedora-extras-list/2006-February/msg01720.html My personal advice is that Enrico gave right answers to the security issues by doing a real audit of used dietlibc code. I am also confident that he will rebuild in no time if there is a security issue in dietlibc. He also gave numbers explaining why there is a big gain in efficiency. The counter arguments were weak in my opinion, like glibc is better in any case, or there should only be one libc. The precedence argument which may have made sense is moot now that the guidelines explicitely require asking FESCO. -- Pat From dbhole at redhat.com Fri May 25 20:46:37 2007 From: dbhole at redhat.com (dbhole) Date: Fri, 25 May 2007 16:46:37 -0400 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524033309.GA15157@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> Message-ID: <1180125997.31894.0.camel@tocatta.toronto.redhat.com> On Wed, 2007-05-23 at 23:33 -0400, Bill Nottingham wrote: > maven2-2.0.4-10jpp.6.fc7 > maven-doxia-1.0-0.1.a7.3jpp.3.fc7 > maven-jxr-1.0-2jpp.2.fc7 > maven-scm-1.0-0.1.b3.2jpp.1.fc7 > maven-shared-1.0-4jpp.2.fc7 > maven-surefire-1.5.3-2jpp.2.fc7 > plexus-ant-factory-1.0-0.1.a1.2jpp.2.fc7 > plexus-appserver-1.0-0.1.a5.3jpp.2.fc7 > plexus-bsh-factory-1.0-0.1.a7s.2jpp.2.fc7 > plexus-cdc-1.0-0.1.a4.2jpp.2.fc7 > plexus-maven-plugin-1.2-2jpp.1.fc7 > plexus-runtime-builder-1.0-0.1.a9.2jpp.1.fc7 > plexus-xmlrpc-1.0-0.1.b4.3jpp.5.fc7 Most of these are directly/indirectly related to maven2 not building. The reason for the problem is not yet known (it hasn't been reduced to a simpler test case yet). I will be looking into it as soon as I can find some time. In the mean time, there is an open bug for it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239123 Cheers, Deepak From tibbs at math.uh.edu Fri May 25 22:36:18 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 25 May 2007 17:36:18 -0500 Subject: Static library exception for flex Message-ID: I've agreed to give the merge review of flex (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225758) a once over, since there was confusion about whether it had been reviewed and approved. The package is clean, and given that it's obviously a development-only package it gets a pass on things like including header files in the main package. However, it also includes a static library, libfl.a, which every flex-using application links against. And according to our guidelines, this needs an ack from FESCo. I can't imagine that we'd break every flex-using application by changing the way it works, but I figure it's better to follow proper procedure here. So, comments? - J< From wart at kobold.org Sat May 26 01:45:56 2007 From: wart at kobold.org (Michael Thomas) Date: Fri, 25 May 2007 18:45:56 -0700 Subject: final kernel biult In-Reply-To: <20070525200754.GA10698@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> Message-ID: <46579154.1050605@kobold.org> Dave Jones wrote: > On Fri, May 25, 2007 at 12:22:06PM -0500, Rex Dieter wrote: > > Dave Jones wrote: > > > On Fri, May 25, 2007 at 11:32:22PM +0800, Yuan Yijun wrote: > > > > 2007/5/25, Bastien Nocera : > > > > > On Thu, 2007-05-24 at 22:29 -0400, Bill Nottingham wrote: > > > > > > kernel-2.6.21-1.3194.fc7 *should* be the final kernel for Fedora 7, > > > > > > barring any late-breaking issues. If you have kmod packages that > > > > > > need built, you should build them now. > > > > > > > > > > For what it's worth, kernel-2.6.21-1.3194.fc7 doesn't even seem to boot > > > > > on my laptop. > > > > > > > > > > > > > meeee too. Dell e1405(640m) don't boot with 3194 or 3201. > > > > > > What was the last one that did boot ? > > > > for me, 3168. > > maxcpus=1 works for later later kernels (3194, 3201) > > > > For posterity, see also: > > http://bugzilla.redhat.com/241249 > > Trying to spot a pattern here is hard. Because so far, it seems to be all Dell > users, but not all Dell core-duo laptops seem to be affected. > My precision M65 for instance is fine. Apparently the problem is not even consistent across models. My Precision M65 is affected. Booting with maxcpus=1 fixes it. > Looking at the diffs between the kernels, the only Dell specific stuff > shouldn't affect the various models seeing problems. (They key off the DMI data) --Wart From bpepple at fedoraproject.org Sat May 26 14:20:38 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 26 May 2007 10:20:38 -0400 Subject: Plan for tomorrows (20070524) FESCO meeting In-Reply-To: <20070525200238.GC2902@free.fr> References: <1179965509.5783.7.camel@lincoln> <20070525200238.GC2902@free.fr> Message-ID: <1180189238.6298.0.camel@lincoln> On Fri, 2007-05-25 at 22:02 +0200, Patrice Dumas wrote: > On Wed, May 23, 2007 at 08:11:49PM -0400, Brian Pepple wrote: > > Please find below the list of topics that are likely to come up in the > > next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC > > in #fedora-meeting on irc.freenode.org: > > I'd like to have FESCO advice on linking ipsvd statically against > dietlibc. It is Enrico choice on the ipsvd submission > I'll add it to the agenda for next weeks meeting. Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora-maintainers at redhat.com Sun May 27 02:49:27 2007 From: fedora-maintainers at redhat.com (Investor Elma) Date: Sat, 26 May 2007 22:49:27 -0400 Subject: Daily News 76265472 Message-ID: <20070527100015.65294.qmail@host-130.AOYAMA.macomnet.net> An HTML attachment was scrubbed... URL: From mszpak at wp.pl Sun May 27 11:27:37 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Sun, 27 May 2007 13:27:37 +0200 Subject: A new version of gnome-applet-sensors Message-ID: <46596B29.6010407@wp.pl> Hi, There is a problem with an actualization of gnome-applet-sensors package. In a rawhide there is 1.7.8 which is over half a year old (current is 1.7.12). In the meantime a few quite important bugs were fixed and support for some new sensors was added [1]. [1] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 I had sent two mails (in March and April) to package maintainer Aaron Kurtz, but I haven't got any reply. Mentioned bug was tagged with FE7Target. Nevertheless it won't be in a base version it would be nice to have it fast in updates. Is there Aaron somewhere around? If yes, please let us know if you plan to maintain gnome-applet-sensors. If no or in case of no reply maybe someone else would be interested in (co)maintaining gnome-applet-sensors? Regards Marcin From nicolas.mailhot at laposte.net Sun May 27 11:55:08 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 May 2007 13:55:08 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <46596B29.6010407@wp.pl> References: <46596B29.6010407@wp.pl> Message-ID: <1180266908.11117.6.camel@rousalka.dyndns.org> Le dimanche 27 mai 2007 ? 13:27 +0200, Marcin Zaj?czkowski a ?crit : > Is there Aaron somewhere around? > If yes, please let us know if you plan to maintain gnome-applet-sensors. Another datapoint (since I filled the update bug and obviously use the stuff) - version bump + rebuild is trivial - any potential (co) maintainer should be ready to deal with upstream's use of the sf.net bugtracker (ie not hate it like me) - upstream can be slow to respond - the lm_sensors upstream maintainer has expressed distress at gnome-applet-sensors several times, breakage when kernel/lm_sensors is updated is to be expected -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bpepple at fedoraproject.org Sun May 27 14:24:30 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 27 May 2007 10:24:30 -0400 Subject: FESCo Meeting Summary for 2007-05-24 Message-ID: <1180275870.5727.4.camel@lincoln> Members Present * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Jesse Keating (f13) * Toshio Kuratomi (abadger1999) * Bill Nottingham (notting) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jeremy Katz (jeremy) * Tom Callaway (spot) * Rex Dieter (rdieter) * Christian Iseli (c4chris) Absent * Warren Togami (warren) * Josh Boyer (jwb) Summary Static libs packaging guidelines changes * FESCo had no objections to the changes to the static libs packaging guideline by the Packaging Committee. https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00926.html Static libs package- cernlib & paw * cernlib should conform to the packaging guidelines for static libs, namely that it's static libs be in a -static subpackage. * It's alright to statically link paw, but it needs a blocker bug opened on it, so that it can be fixed in the near future. Proposal on how to handle violations of the packaging guideline * FESCo approved pjones proposal. https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00634.html For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070524 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Sun May 27 16:20:02 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 27 May 2007 18:20:02 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <1180266908.11117.6.camel@rousalka.dyndns.org> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> Message-ID: <4659AFB2.2070005@hhs.nl> Nicolas Mailhot wrote: > - the lm_sensors upstream maintainer has expressed distress at > gnome-applet-sensors several times, breakage when kernel/lm_sensors is > updated is to be expected > I am active in the upstream lm_sensors project, can you explain? Maybe this can be fixed the same way I fixed gkrellm (use libsensors instead of DIY) Regards, Hans From pertusus at free.fr Sun May 27 16:58:54 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 27 May 2007 18:58:54 +0200 Subject: FESCo Meeting Summary for 2007-05-24 In-Reply-To: <1180275870.5727.4.camel@lincoln> References: <1180275870.5727.4.camel@lincoln> Message-ID: <20070527165845.GB2841@free.fr> On Sun, May 27, 2007 at 10:24:30AM -0400, Brian Pepple wrote: > > Static libs package- cernlib & paw > * cernlib should conform to the packaging guidelines for static > libs, namely that it's static libs be in a -static subpackage. Ok... I am not very happy with that since I fear it will break users expectations, however it may also help shape users expectations that static libs are in separate packages. Testing local build right now and building it in koji as soon as possible. > * It's alright to statically link paw, but it needs a blocker bug > opened on it, so that it can be fixed in the near future. If you like. This is something which is working on or more precisely known where it should, but opening a bug is not that problematic. There was a bug opened because paw wasn't working https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=192866 Should I reopen that bug, or open a new one? As a side note I didn't found a bug opened in debian, although this is where it would currently make much more sense. A more detailed explanation is there, for those who want to know more: http://people.debian.org/~kmccarty/cernlib/faq.html#41 If somebody is willing to work on that that would be incredible, but I am not very confident it is gonna happen ;-). -- Pat From nicolas.mailhot at laposte.net Sun May 27 23:13:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 May 2007 01:13:12 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <4659AFB2.2070005@hhs.nl> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> Message-ID: <1180307592.3493.5.camel@rousalka.dyndns.org> Le dimanche 27 mai 2007 ? 18:20 +0200, Hans de Goede a ?crit : > Nicolas Mailhot wrote: > > - the lm_sensors upstream maintainer has expressed distress at > > gnome-applet-sensors several times, breakage when kernel/lm_sensors is > > updated is to be expected > > > > I am active in the upstream lm_sensors project, can you explain? Maybe this can > be fixed the same way I fixed gkrellm (use libsensors instead of DIY) In the few cases I remember gnome-applet-sensors made bad assumptions, so rebuilding it against a newer lm_sensors wasn't sufficient to pick up new stuff, it also needed internal changes (for example, every sensor is on a bus when the k8/core2 sensors are on a processor, etc) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From petersen at redhat.com Mon May 28 01:58:39 2007 From: petersen at redhat.com (Jens Petersen) Date: Mon, 28 May 2007 11:58:39 +1000 Subject: cvs-import.sh should now tag correctly In-Reply-To: <464DCAD3.7070503@hhs.nl> References: <464DCAD3.7070503@hhs.nl> Message-ID: <465A374F.5090305@redhat.com> Hans de Goede ????????: > I just imported 2 new packages with > cvs-import.sh and it created xxx_fc7 tags in the devel dir of those > packages, whereas make tag does do the right thing. I updated cvs-import.sh to use "make tag" instead of trying to "cvs tag" directly which hopefully should fix the tagging problems people have seen with the script. It has been tested by someone who uses the script to update packages in cvs. For people who only use the script initially to import new packages to devel the change should be transparent, but it should now tag packages imported to branch dirs correctly too. Please let me know if there are any problems. Jens From davej at redhat.com Mon May 28 02:49:22 2007 From: davej at redhat.com (Dave Jones) Date: Sun, 27 May 2007 22:49:22 -0400 Subject: final kernel biult In-Reply-To: <46579154.1050605@kobold.org> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> Message-ID: <20070528024922.GA28277@redhat.com> On Fri, May 25, 2007 at 06:45:56PM -0700, Michael Thomas wrote: > > > for me, 3168. > > > maxcpus=1 works for later later kernels (3194, 3201) > > > > > > For posterity, see also: > > > http://bugzilla.redhat.com/241249 > > > > Trying to spot a pattern here is hard. Because so far, it seems to be all Dell > > users, but not all Dell core-duo laptops seem to be affected. > > My precision M65 for instance is fine. > > Apparently the problem is not even consistent across models. My > Precision M65 is affected. Booting with maxcpus=1 fixes it. Argh! Can people seeing this problem try out kernel-2.6.21-1.3206.fc7 from http://people.redhat.com/davej/kernels/Fedora/fc7/ Dave -- http://www.codemonkey.org.uk From wart at kobold.org Mon May 28 03:48:08 2007 From: wart at kobold.org (Michael Thomas) Date: Sun, 27 May 2007 20:48:08 -0700 Subject: final kernel biult In-Reply-To: <20070528024922.GA28277@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> Message-ID: <465A50F8.4060009@kobold.org> Dave Jones wrote: > On Fri, May 25, 2007 at 06:45:56PM -0700, Michael Thomas wrote: > > > > > for me, 3168. > > > > maxcpus=1 works for later later kernels (3194, 3201) > > > > > > > > For posterity, see also: > > > > http://bugzilla.redhat.com/241249 > > > > > > Trying to spot a pattern here is hard. Because so far, it seems to be all Dell > > > users, but not all Dell core-duo laptops seem to be affected. > > > My precision M65 for instance is fine. > > > > Apparently the problem is not even consistent across models. My > > Precision M65 is affected. Booting with maxcpus=1 fixes it. > > Argh! > Can people seeing this problem try out kernel-2.6.21-1.3206.fc7 > from http://people.redhat.com/davej/kernels/Fedora/fc7/ I didn't see that build at the url you gave, but I grabbed the 3206 build from koji. build 3206 boots just fine for me now, while 3194 continues to hang. --Mike From davej at redhat.com Mon May 28 04:05:08 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 28 May 2007 00:05:08 -0400 Subject: final kernel biult In-Reply-To: <465A50F8.4060009@kobold.org> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> Message-ID: <20070528040508.GC28277@redhat.com> On Sun, May 27, 2007 at 08:48:08PM -0700, Michael Thomas wrote: > Dave Jones wrote: > > On Fri, May 25, 2007 at 06:45:56PM -0700, Michael Thomas wrote: > > > > > > > for me, 3168. > > > > > maxcpus=1 works for later later kernels (3194, 3201) > > > > > > > > > > For posterity, see also: > > > > > http://bugzilla.redhat.com/241249 > > > > > > > > Trying to spot a pattern here is hard. Because so far, it seems to be all Dell > > > > users, but not all Dell core-duo laptops seem to be affected. > > > > My precision M65 for instance is fine. > > > > > > Apparently the problem is not even consistent across models. My > > > Precision M65 is affected. Booting with maxcpus=1 fixes it. > > > > Argh! > > Can people seeing this problem try out kernel-2.6.21-1.3206.fc7 > > from http://people.redhat.com/davej/kernels/Fedora/fc7/ > > I didn't see that build at the url you gave Ah, I need to teach my mirroring script how to cope with freezes :) > , but I grabbed the 3206 > build from koji. build 3206 boots just fine for me now, while 3194 > continues to hang. Ok, that's good to know. That narrows it down to something in 2.6.21.2 I'm still not entirely sure *which* patch in that update caused the problem, so I'll do a few more builds to try and narrow things down further. Thanks for testing. Dave -- http://www.codemonkey.org.uk From j.w.r.degoede at hhs.nl Mon May 28 07:51:18 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 28 May 2007 09:51:18 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <1180307592.3493.5.camel@rousalka.dyndns.org> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> Message-ID: <465A89F6.2000700@hhs.nl> Nicolas Mailhot wrote: > Le dimanche 27 mai 2007 ? 18:20 +0200, Hans de Goede a ?crit : >> Nicolas Mailhot wrote: >>> - the lm_sensors upstream maintainer has expressed distress at >>> gnome-applet-sensors several times, breakage when kernel/lm_sensors is >>> updated is to be expected >>> >> I am active in the upstream lm_sensors project, can you explain? Maybe this can >> be fixed the same way I fixed gkrellm (use libsensors instead of DIY) > > In the few cases I remember gnome-applet-sensors made bad assumptions, > so rebuilding it against a newer lm_sensors wasn't sufficient to pick up > new stuff, it also needed internal changes (for example, every sensor is > on a bus when the k8/core2 sensors are on a processor, etc) > Oh, but libsensors itself is full of assumptions like that so upstream really shouldn't be complaining about gnome-applet-sensors making assumptions like that :) Either way I volunteer myself as co-maintainer for gnome-applet-sensors, because of my involvednes in lmsensors upstream. Regards, Hans From bbbush.yuan at gmail.com Mon May 28 16:08:43 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 29 May 2007 00:08:43 +0800 Subject: final kernel biult In-Reply-To: <20070528040508.GC28277@redhat.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <1180103717.14752.41.camel@cookie.hadess.net> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> <20070528040508.GC28277@redhat.com> Message-ID: <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> Dell e1405/640m (CPU T2300E) kernel 3190 and 3191, 3206 boots fine. kernel 3194, 3201, 3207 failed even with maxcups=1 -- bbbush ^_^ From bbbush.yuan at gmail.com Mon May 28 16:20:15 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 29 May 2007 00:20:15 +0800 Subject: final kernel biult In-Reply-To: <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> <20070528040508.GC28277@redhat.com> <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> Message-ID: <76e72f800705280920ic4cfbb1o68c1bafde0df4ea0@mail.gmail.com> 2007/5/29, Yuan Yijun : > Dell e1405/640m (CPU T2300E) > kernel 3190 and 3191, 3206 boots fine. > kernel 3194, 3201, 3207 failed even with maxcups=1 > oops. I owe you a thousand cups of beer. maxcpus=1 works. :) -- bbbush ^_^ From davej at redhat.com Mon May 28 17:17:46 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 28 May 2007 13:17:46 -0400 Subject: final kernel biult In-Reply-To: <76e72f800705280920ic4cfbb1o68c1bafde0df4ea0@mail.gmail.com> References: <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> <20070528040508.GC28277@redhat.com> <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> <76e72f800705280920ic4cfbb1o68c1bafde0df4ea0@mail.gmail.com> Message-ID: <20070528171746.GA12135@redhat.com> On Tue, May 29, 2007 at 12:20:15AM +0800, Yuan Yijun wrote: > 2007/5/29, Yuan Yijun : > > Dell e1405/640m (CPU T2300E) > > kernel 3190 and 3191, 3206 boots fine. > > kernel 3194, 3201, 3207 failed even with maxcups=1 > > > > oops. I owe you a thousand cups of beer. > maxcpus=1 works. :) Ok. I'll kick off a 3208 with another suspect patch removed. 1 down, n to go.. Dave -- http://www.codemonkey.org.uk From fedora at leemhuis.info Mon May 28 18:34:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 28 May 2007 20:34:34 +0200 Subject: EPEL report week 20, 2007 Message-ID: <465B20BA.4070701@leemhuis.info> Hi all! Please find below this weeks EPEL report. It's also in the wiki at http://fedoraproject.org/wiki/EPEL/Reports/Week21 Cu knurd ---- = Weekly EPEL Summary = Week 21/2007 == Most important happenings == * [https://www.redhat.com/archives/epel-devel-list/2007-May/msg00138.html Noisy discussions] in reply to the meeting summary after the "repotags/interaction with 3rd party repos" topic was discussed and removed from the schedule; knurd will nevertheless bring it up in the next meeting again, as it was no formal discussion (only three Steering Committee members around then) == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) (partly) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * dgilmore (DennisGilmore) * quiad (KarstenWade) Others that participated the meeting: LetoTo, Jeff_S, rdieter, f13, smooge === Summary === * 00:03 --- | knurd has changed the topic to: EPEL Meeting -- repotags/interaction with 3rd party repos -- owner: all * I'm not going to write a summary on this, as this is a very controversial and complicated topic. Sorry. Please read the full log. * 00:45 --- | mmcgrath has changed the topic to: EPEL Meeting -- Investigate single RHEL subscription for EPEL maintainers -- quaid * "It would be nice to get some RHEL subscriptions for our EPEL people though I think quaid has quite a journey ahead of him first. It may be easier once red hat can more easily realize the value of EPEL. knurd> | I don't think this is high on out todo list; we'll talk about this next time when quaid is around. * 00:49 --- | mmcgrath has changed the topic to: EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken * we need to look at converting epel to koji; f13> "there are some roadblocks to that. like koji modifications that would make the binaries used in the buildroots not publically available." * some discussions around RH management, using RHEL for Building and not CentOS * mbonnet will look into enabling koji to make use of a repo htat's not available to the public, which should make it possible to use koji for EPEL * lmacken> "bodhi would work with plague if we could get it filesystem access to the build results." ; he'll likely look into this, too, but making bodhi working for F7 is more important atm === Full meeting log === See https://www.redhat.com/archives/epel-devel-list/2007-May/msg00138.html == Stats == === General === Number of EPEL Contributors 80 We welcome 6 new contributors: ed_AT_eh3.com, jspaleta_AT_gmail.com, limb_AT_jcomserv.net, phuang_AT_redhat.com, pnemade_AT_redhat.com, tagoh_AT_redhat.com, zhu_AT_redhat.com === EPEL 5 === Number of source packages: 292 Number of binary packages: 470 There are 67 new Packages: * arp-scan | Scanning and fingerprinting tool * autodir | Creates user directories on demand * bugzilla | Bug tracking system * cgdb | CGDB is a curses-based interface to the GNU Debugger (GDB) * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * drgeo | Interactive educational geometry software * freehdl | GPLed free VHDL * gammu | Command Line utility to work with mobile phones * gperiodic | Program for browsing the periodic table * graphviz | Graph Visualization Tools * halberd | Tool to discover HTTP load balancers * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * incron | Inotify cron system * ircd-hybrid | Internet Relay Chat Server * jasper | Implementation of the JPEG-2000 standard, Part 1 * libiptcdata | IPTC tag library * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * ncarg | A Fortran and C based software package for scientific visualization * netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3) * nrpe | Host/service/network monitoring agent for Nagios * ocaml | Objective Caml compiler and programming environment * pdns | A modern, advanced and high performance authoritative-only nameserver * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Affix-Infix2Postfix | Perl extension for converting from infix notation to postfix notation * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-DBD-SQLite | Self Contained RDBMS in a DBI Driver * perl-HTML-Table | Create HTML tables using simple interface * perl-Image-Math-Constrain | Scaling math used in image size constraining (such as thumbnails) * perl-IO-Multiplex | IO-Multiplex module for perl * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Math-Base85 | Perl extension for base 85 numbers, as referenced by RFC 1924 * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-Net-Pcap | Interface to pcap(3) LBL packet capture library * perl-Nmap-Parser | Parse nmap scan data with perl * perl-Proc-Daemon | Run Perl program as a daemon process * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * php-channel-phpunit | Adds phpunit channel to PEAR * php-pear-DB | PEAR: Database Abstraction Layer * php-pear-Log | Abstracted logging facility for PHP * php-pear-Net-Ping | Execute ping * php-pear-Net-Traceroute | Execute traceroute * php-pecl-radius | Radius client library * php-pecl-xdebug | PECL package for debugging PHP scripts * plone | User friendly and powerful open source Content Management System * Pound | Reverse proxy and load balancer * python-cheetah | Template engine and code-generator * python-docutils | A system for processing plaintext documentation * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * python-protocols | Open Protocols and Component Adaptation for Python * python-sqlite2 | DB-API 2.0 interface for SQLite 3.x * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * ushare | UPnP (TM) A/V Media Server * windowlab | Small and Simple Amiga-like Window Manager * yum-arch | Extract headers from rpm in a old yum repository * zope | Web application server for flexible content management applications === EPEL 4 === Number of source packages: 194 Number of binary packages: 358 There are 36 new Packages: * bugzilla | Bug tracking system * DMitry | Deepmagic Information Gathering Tool * drgeo-doc | Html documentation for drgeo * drgeo | Interactive educational geometry software * freehdl | GPLed free VHDL * gperiodic | Program for browsing the periodic table * halberd | Tool to discover HTTP load balancers * ike-scan | IKE protocol tool to discover, fingerprint and test IPsec VPN servers * ircd-hybrid | Internet Relay Chat Server * libupnp | Universal Plug and Play (UPnP) SDK * nbtscan | Tool to gather NetBIOS info from Windows networks * ncarg | A Fortran and C based software package for scientific visualization * netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3) * ocaml | Objective Caml compiler and programming environment * pdns-recursor | Modern, advanced and high performance recursing/non authoritative nameserver * perl-Apache-DBI | Persistent database connections with Apache/mod_perl * perl-Boulder | An API for hierarchical tag/value structures * perl-HTML-Table | Create HTML tables using simple interface * perl-libwhisker2 | Perl module geared specificly for HTTP testing * perl-Math-Base85 | Perl extension for base 85 numbers, as referenced by RFC 1924 * perl-Net-IP-CMatch | Efficiently match IP addresses against IP ranges with C * perl-Net-Patricia | Patricia Trie perl module for fast IP address lookups * perl-Nmap-Parser | Parse nmap scan data with perl * perl-Proc-Daemon | Run Perl program as a daemon process * perl-String-Approx | Perl extension for approximate matching (fuzzy matching) * perl-XML-DOM | DOM extension to XML::Parser * perl-XML-RegExp | Regular expressions for XML tokens * Pound | Reverse proxy and load balancer * python-krbV | Python extension module for Kerberos 5 * python-numarray | Python array manipulation and computational library * qucs | Circuit simulator * ruby-mysql | A Ruby interface to MySQL * scponly | Restricted shell for ssh based file services * specto | An desktop application that will watch configurable events * ushare | UPnP (TM) A/V Media Server * windowlab | Small and Simple Amiga-like Window Manager ---- ["CategoryEPELReports"] From wart at kobold.org Mon May 28 23:34:32 2007 From: wart at kobold.org (Wart) Date: Mon, 28 May 2007 16:34:32 -0700 Subject: final kernel biult In-Reply-To: <20070528171746.GA12135@redhat.com> References: <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> <20070528040508.GC28277@redhat.com> <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> <76e72f800705280920ic4cfbb1o68c1bafde0df4ea0@mail.gmail.com> <20070528171746.GA12135@redhat.com> Message-ID: <465B6708.2070204@kobold.org> Dave Jones wrote: > On Tue, May 29, 2007 at 12:20:15AM +0800, Yuan Yijun wrote: > > 2007/5/29, Yuan Yijun : > > > Dell e1405/640m (CPU T2300E) > > > kernel 3190 and 3191, 3206 boots fine. > > > kernel 3194, 3201, 3207 failed even with maxcups=1 > > > > > > > oops. I owe you a thousand cups of beer. > > maxcpus=1 works. :) > > Ok. I'll kick off a 3208 with another suspect patch removed. > 1 down, n to go.. On my Precision M65: 3207 == bad, unless maxcpus=1 3208 == good --Wart From davej at redhat.com Tue May 29 00:55:18 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 28 May 2007 20:55:18 -0400 Subject: final kernel biult In-Reply-To: <465B6708.2070204@kobold.org> References: <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> <20070528040508.GC28277@redhat.com> <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> <76e72f800705280920ic4cfbb1o68c1bafde0df4ea0@mail.gmail.com> <20070528171746.GA12135@redhat.com> <465B6708.2070204@kobold.org> Message-ID: <20070529005518.GA5767@redhat.com> On Mon, May 28, 2007 at 04:34:32PM -0700, Wart wrote: > Dave Jones wrote: > > On Tue, May 29, 2007 at 12:20:15AM +0800, Yuan Yijun wrote: > > > 2007/5/29, Yuan Yijun : > > > > Dell e1405/640m (CPU T2300E) > > > > kernel 3190 and 3191, 3206 boots fine. > > > > kernel 3194, 3201, 3207 failed even with maxcups=1 > > > > > > > > > > oops. I owe you a thousand cups of beer. > > > maxcpus=1 works. :) > > > > Ok. I'll kick off a 3208 with another suspect patch removed. > > 1 down, n to go.. > > On my Precision M65: > > 3207 == bad, unless maxcpus=1 > 3208 == good Fascinating. That patch was in an earlier Fedora kernel before it found its way into -stable, and I don't recall it having anywhere near the same amount of problems. I'll point this out upstream. Can others with problems confirm that 3208 works without maxcpus=1 ? Dave -- http://www.codemonkey.org.uk From bbbush.yuan at gmail.com Tue May 29 14:14:37 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 29 May 2007 22:14:37 +0800 Subject: final kernel biult In-Reply-To: <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> References: <20070525022925.GA29021@nostromo.devel.redhat.com> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> <20070528040508.GC28277@redhat.com> <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> Message-ID: <76e72f800705290714g32391b9dy98c92d06ff100185@mail.gmail.com> 2007/5/29, Yuan Yijun : > Dell e1405/640m (CPU T2300E) > kernel 3190 and 3191, 3206 boots fine. > kernel 3194, 3201, 3207 failed even with maxcups=1 > kernel 3208 works, don't need to specify maxcpus=1 btw in this version iwl3945 works alright. rmmod has no problem. signal strength is fine. reboot don't hang. btw2 with this version suspend to disk works for me. -- bbbush ^_^ From rdieter at math.unl.edu Tue May 29 14:39:03 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 29 May 2007 09:39:03 -0500 Subject: final kernel biult References: <20070525022925.GA29021@nostromo.devel.redhat.com> <76e72f800705250832s59bfc7ccmab6dbd4acbac1347@mail.gmail.com> <20070525163104.GA26902@redhat.com> <46571B3E.7070208@math.unl.edu> <20070525200754.GA10698@redhat.com> <46579154.1050605@kobold.org> <20070528024922.GA28277@redhat.com> <465A50F8.4060009@kobold.org> <20070528040508.GC28277@redhat.com> <76e72f800705280908p4913666q6ffb18307229012f@mail.gmail.com> <76e72f800705290714g32391b9dy98c92d06ff100185@mail.gmail.com> Message-ID: <200705291439.l4TEd3FT010934@mathstat.unl.edu> Yuan Yijun wrote: >> Dell e1405/640m (CPU T2300E) >> kernel 3190 and 3191, 3206 boots fine. >> kernel 3194, 3201, 3207 failed even with maxcups=1 > kernel 3208 works, don't need to specify maxcpus=1 3208 worksforme too (dell d620), yay. -- Rex From mszpak at wp.pl Tue May 29 18:36:04 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Tue, 29 May 2007 20:36:04 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <465A89F6.2000700@hhs.nl> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> <465A89F6.2000700@hhs.nl> Message-ID: <465C7294.4080700@wp.pl> On 2007-05-28 9:51:18 +0200, Hans de Goede wrote: (...) > Either way I volunteer myself as co-maintainer for gnome-applet-sensors, > because of my involvednes in lmsensors upstream. Great! Even though we are still waiting for Aaron Kurtz reply I think that having comaintainer will be good for g-a-s anyway, especially that F7 (and updates for it) will be available for thousands of Fedora users very soon. In my opinion you could start procedure of comaintainer addition [1] and update a package (also for FC-5 and FC-6 branches). [1] - http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure Regards Marcin From kwade at redhat.com Tue May 29 18:44:06 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 29 May 2007 11:44:06 -0700 Subject: Web-only release notes deadline 30 May 23:59 UTC Message-ID: <1180464246.3439.1220.camel@erato.phig.org> *** Last Chance for Web-only Release Notes *** Tomorrow (30 May) at 23:59 UTC we are freezing this part of the Wiki: http://fedoraproject.org/wiki/Docs/Beats We'll be putting any additions made to the Beats into the release notes. These are then published on 31 May here: http://docs.fedoraproject.org/release-notes This URL is specified now at the top of every page of the release notes, so it is a highly visible way to get any last-minute notes available. Following the release of Fedora 7, we'll push out an update to fedora-release-notes, after a short interval for translation. http://fedoraproject.org/wiki/DocsProject/Schedule#relnotes-schedule thx - your Fedora Documentation Project [Also posted to f-devel-l] -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Tue May 29 18:58:56 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 29 May 2007 20:58:56 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <465C7294.4080700@wp.pl> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> <465A89F6.2000700@hhs.nl> <465C7294.4080700@wp.pl> Message-ID: <465C77F0.4090108@hhs.nl> Marcin Zaj?czkowski wrote: > On 2007-05-28 9:51:18 +0200, Hans de Goede wrote: > (...) >> Either way I volunteer myself as co-maintainer for gnome-applet-sensors, >> because of my involvednes in lmsensors upstream. > > Great! Even though we are still waiting for Aaron Kurtz reply I think > that having comaintainer will be good for g-a-s anyway, especially that > F7 (and updates for it) will be available for thousands of Fedora users > very soon. > In my opinion you could start procedure of comaintainer addition [1] and > update a package (also for FC-5 and FC-6 branches). > That would be more like a package take-over then co-maintainer ship. I'll start working on gnome-applet-sensors as soon as the current maintainer thinks this is a good idea and not a minute earlier. Regards, Hans From bugs.michael at gmx.net Tue May 29 18:54:50 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 29 May 2007 20:54:50 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <465C7294.4080700@wp.pl> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> <465A89F6.2000700@hhs.nl> <465C7294.4080700@wp.pl> Message-ID: <20070529205450.38f8fd12.bugs.michael@gmx.net> On Tue, 29 May 2007 20:36:04 +0200, Marcin Zaj?czkowski wrote: > On 2007-05-28 9:51:18 +0200, Hans de Goede wrote: > (...) > > Either way I volunteer myself as co-maintainer for gnome-applet-sensors, > > because of my involvednes in lmsensors upstream. > > Great! Even though we are still waiting for Aaron Kurtz reply I think > that having comaintainer will be good for g-a-s anyway, especially that > F7 (and updates for it) will be available for thousands of Fedora users > very soon. > In my opinion you could start procedure of comaintainer addition [1] and > update a package (also for FC-5 and FC-6 branches). > > [1] - http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure Rather start the AWOL procedure first. From mszpak at wp.pl Tue May 29 19:19:32 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Tue, 29 May 2007 21:19:32 +0200 Subject: AWOL vs. adding comaintainer (Was: Re: A new version of gnome-applet-sensors) In-Reply-To: <20070529205450.38f8fd12.bugs.michael@gmx.net> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> <465A89F6.2000700@hhs.nl> <465C7294.4080700@wp.pl> <20070529205450.38f8fd12.bugs.michael@gmx.net> Message-ID: <465C7CC4.4090200@wp.pl> On 2007-05-29 20:54:50 +0200, Michael Schwendt wrote: > On Tue, 29 May 2007 20:36:04 +0200, Marcin Zaj?czkowski wrote: > >> On 2007-05-28 9:51:18 +0200, Hans de Goede wrote: >> (...) >>> Either way I volunteer myself as co-maintainer for gnome-applet-sensors, >>> because of my involvednes in lmsensors upstream. >> Great! Even though we are still waiting for Aaron Kurtz reply I think >> that having comaintainer will be good for g-a-s anyway, especially that >> F7 (and updates for it) will be available for thousands of Fedora users >> very soon. >> In my opinion you could start procedure of comaintainer addition [1] and >> update a package (also for FC-5 and FC-6 branches). >> >> [1] - http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > Rather start the AWOL procedure first. I thought about AWOL, but it takes more time. Adding comaintainer could be faster, but I don't know if it's required permission for current maintainer to become a comaintainer? 2. Could be already mentioned bug [2] considered as a "asking for the maintainer to respond"? 3. Has to be whole procedure carried by a person who want to take the package over or (s)he has to only post a formal request to the maintainers list? [2] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 Regards Marcin From bugs.michael at gmx.net Tue May 29 19:52:48 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 29 May 2007 21:52:48 +0200 Subject: AWOL vs. adding comaintainer (Was: Re: A new version of gnome-applet-sensors) In-Reply-To: <465C7CC4.4090200@wp.pl> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> <465A89F6.2000700@hhs.nl> <465C7294.4080700@wp.pl> <20070529205450.38f8fd12.bugs.michael@gmx.net> <465C7CC4.4090200@wp.pl> Message-ID: <20070529215248.7d2dbb85.bugs.michael@gmx.net> On Tue, 29 May 2007 21:19:32 +0200, Marcin Zaj?czkowski wrote: > On 2007-05-29 20:54:50 +0200, Michael Schwendt wrote: > > On Tue, 29 May 2007 20:36:04 +0200, Marcin Zaj?czkowski wrote: > > > >> On 2007-05-28 9:51:18 +0200, Hans de Goede wrote: > >> (...) > >>> Either way I volunteer myself as co-maintainer for gnome-applet-sensors, > >>> because of my involvednes in lmsensors upstream. > >> Great! Even though we are still waiting for Aaron Kurtz reply I think > >> that having comaintainer will be good for g-a-s anyway, especially that > >> F7 (and updates for it) will be available for thousands of Fedora users > >> very soon. > >> In my opinion you could start procedure of comaintainer addition [1] and > >> update a package (also for FC-5 and FC-6 branches). > >> > >> [1] - http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > > > Rather start the AWOL procedure first. > > I thought about AWOL, but it takes more time. Adding comaintainer could > be faster, but I don't know if it's required permission for current > maintainer to become a comaintainer? The people who process the change requests for owners.list need to check that there is no hostile take-over. > 2. Could be already mentioned bug [2] considered as a "asking for the > maintainer to respond"? It could be taken into account as a tiny amount [i.e. maybe a few days off the waiting periods during the AWOL procedure], but it cannot be used to skip the entire procedure IMO. While it is not nice of the package owner to not respond in bugzilla for over a month, it is too easy to not pay attention to bugzilla tickets, where somebody requests a version upgrade. I recommend that the AWOL procedure is started with explicit words and that the importance of a version upgrade is emphasised also in a private mail. > 3. Has to be whole procedure carried by a person who want to take the > package over or (s)he has to only post a formal request to the > maintainers list? *Somebody* needs to track all contact attempts, and even if there is nobody to take over a package immediately, the community would at least find out that something is orphaned. > > [2] - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235655 > From denis at poolshark.org Wed May 30 11:45:46 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 30 May 2007 13:45:46 +0200 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <20070524033309.GA15157@nostromo.devel.redhat.com> References: <20070524033309.GA15157@nostromo.devel.redhat.com> Message-ID: <465D63EA.7000307@poolshark.org> Bill Nottingham wrote: > As part of the merge, we bootstrapped and imported Extras for ppc64. > > Not all packages built correctly. Logs of the failures are available at: > http://people.redhat.com/notting/ppc64-rebuild/ > > Bugs have only been filed for some of these at this point. Common > failure cases are: > > - build deps: no ocaml support on ppc64 (being worked on) > - build deps: no mono support on ppc64 (needs excludearch) > - inability to build shared libraries. This is due to ancient libtool > stuff in the package; a patch can be found at: > http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=154193 > > The list of packages: > [...] > brasero-0.5.2-1.fc7 "No Package Found for libbeagle-devel >= 0.1.1" It looks as though beagle is not built for ppc64, from the beagle SPEC file: # Mono only available on these: ExclusiveArch: %ix86 x86_64 ppc ia64 armv4l sparc alpha I'll remove beagle support from brasero for ppc64. From jkeating at redhat.com Wed May 30 13:18:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 May 2007 09:18:04 -0400 Subject: ppc64 packages that did not build for dist-fc7 In-Reply-To: <465D63EA.7000307@poolshark.org> References: <20070524033309.GA15157@nostromo.devel.redhat.com> <465D63EA.7000307@poolshark.org> Message-ID: <200705300918.04535.jkeating@redhat.com> On Wednesday 30 May 2007 07:45:46 Denis Leroy wrote: > "No Package Found for libbeagle-devel >= 0.1.1" > > It looks as though beagle is not built for ppc64, from the beagle SPEC > file: > > # Mono only available on these: > ExclusiveArch: %ix86 x86_64 ppc ia64 armv4l sparc alpha > > > I'll remove beagle support from brasero for ppc64. No mono == no beagle. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed May 30 16:10:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 May 2007 12:10:17 -0400 Subject: cvs-import.sh should now tag correctly In-Reply-To: <465A374F.5090305@redhat.com> References: <464DCAD3.7070503@hhs.nl> <465A374F.5090305@redhat.com> Message-ID: <200705301210.17286.jkeating@redhat.com> On Sunday 27 May 2007 21:58:39 Jens Petersen wrote: > Please let me know if there are any problems. Looks like it tagged right, but the output looked a little funny: Commit Complete cvs tag -c pungi-0_3_7-1_fc8 cvs tag: Tagging . T .cvsignore T Makefile T pungi.spec T sources Tagged with: pungi-0_3_7-1_fc8 Tagging 'pungi-0_3_7-1_fc7' complete. So something in the cvs-import.sh script is still translating the value of %{dist} wrong but I think it's cosmetic and not effecting anything. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed May 30 16:34:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 May 2007 12:34:08 -0400 Subject: comps-f8.xml.in created Message-ID: <200705301234.08377.jkeating@redhat.com> For all our Fedora 8 comps loving. Copied from the current comps-f7.xml.in file. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Wed May 30 16:58:22 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 May 2007 11:58:22 -0500 Subject: Summary of the 2007-05-29 Packaging Committee meeting Message-ID: Meeting minutes and full logs of the packaging committee meeting which occurred on 2007-05-29 are online: http://fedoraproject.org/wiki/Packaging/Minutes http://fedoraproject.org/wiki/Packaging/Minutes20070529 Executive summary: The following drafts are now official guidelines, having been accepted by FESCO last week: * Tweaks to static library packaging guidelines: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges This should be written into the guidelines soon if it hasn't already been done by the time you read this. No issues pending FESCO ratification this week. Misc business: * Guidelines for adding Users and Groups * http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups * Serious fundamental issues exist in rpm that prevent any reliable handling of users and groups inside rpm scriptlets. For instance, %pre cannot be allowed to fail, because it seems that it is not possible to abort an RPM transaction. * Clever ideas working around the tough problems would be warmly welcomed. * Fix incorrect information in http://fedoraproject.org/wiki/Packaging/ScriptletSnippets * http://www.redhat.com/archives/fedora-packaging/2007-May/msg00116.html * scop will draft up various changes. * Including in binary packages test suite code that upstream does not install. * There are multiple issues: including things as %doc and actually packaging test binaries in /usr/bin. * There is little committee consensus on this; some members don't care what gets packaged as %doc, some don't want any test suite code packaged at all. * Community opinions are solicited here. * If someone feels strongly enough about the issue, please write up a draft. - J< From bpepple at fedoraproject.org Wed May 30 17:56:48 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 30 May 2007 13:56:48 -0400 Subject: Plan for tomorrows (20070531) FESCO meeting Message-ID: <1180547808.5868.31.camel@lincoln> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 17:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- MISC -- Package Database - abadger1999 /topic FESCO-Meeting -- MISC -- F7 /topic FESCO-Meeting -- linking ipsvd statically against dietlibc -- requested by Patrice Dumas - https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00980.html /topic FESCO-Meeting -- statically link libgcrypt into gaim-otr -- requested by Paul Wouters - http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00425.html /topic FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb /topic FESCO-Meeting -- MISC -- Policies that need updating for merge? -- http://fedoraproject.org/wiki/PackageMaintainers/Policy /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Wed May 30 18:13:08 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 May 2007 13:13:08 -0500 Subject: Plan for tomorrows (20070531) FESCO meeting In-Reply-To: <1180547808.5868.31.camel@lincoln> References: <1180547808.5868.31.camel@lincoln> Message-ID: >>>>> "BP" == Brian Pepple writes: BP> You want something to be discussed? I'd like to discuss a blanket exception for packages which link against flex's libfl.a. - J< From bpepple at fedoraproject.org Wed May 30 18:30:17 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 30 May 2007 14:30:17 -0400 Subject: Plan for tomorrows (20070531) FESCO meeting In-Reply-To: References: <1180547808.5868.31.camel@lincoln> Message-ID: <1180549817.5868.34.camel@lincoln> On Wed, 2007-05-30 at 13:13 -0500, Jason L Tibbitts III wrote: > >>>>> "BP" == Brian Pepple writes: > > BP> You want something to be discussed? > > I'd like to discuss a blanket exception for packages which link > against flex's libfl.a. I'll add it the the schedule. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Wed May 30 19:56:56 2007 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 30 May 2007 20:56:56 +0100 Subject: OCaml (was: Re: Plan for tomorrows (20070531) FESCO meeting) In-Reply-To: <1180547808.5868.31.camel@lincoln> References: <1180547808.5868.31.camel@lincoln> Message-ID: <465DD708.2070507@redhat.com> I don't know if this is a suitable topic, or if these meetings are invite only, but if it is and they're not, then review of OCaml packages: http://tinyurl.com/2rl4w6 and any of the issues I raised here: https://www.redhat.com/archives/fedora-packaging/2007-May/msg00207.html Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From tcallawa at redhat.com Wed May 30 19:55:44 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 30 May 2007 14:55:44 -0500 Subject: OCaml (was: Re: Plan for tomorrows (20070531) FESCO meeting) In-Reply-To: <465DD708.2070507@redhat.com> References: <1180547808.5868.31.camel@lincoln> <465DD708.2070507@redhat.com> Message-ID: <1180554944.6254.510.camel@localhost.localdomain> On Wed, 2007-05-30 at 20:56 +0100, Richard W.M. Jones wrote: > I don't know if this is a suitable topic, or if these meetings are > invite only, but if it is and they're not, then review of OCaml packages: > > http://tinyurl.com/2rl4w6 > > and any of the issues I raised here: > > https://www.redhat.com/archives/fedora-packaging/2007-May/msg00207.html This is packaging committee stuff, we're going to tackle OCaml next week. :) ~spot From mszpak at wp.pl Wed May 30 21:14:41 2007 From: mszpak at wp.pl (=?UTF-8?B?TWFyY2luIFphasSFY3prb3dza2k=?=) Date: Wed, 30 May 2007 23:14:41 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <465C77F0.4090108@hhs.nl> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> <465A89F6.2000700@hhs.nl> <465C7294.4080700@wp.pl> <465C77F0.4090108@hhs.nl> Message-ID: <465DE941.9070205@wp.pl> On 2007-05-29 20:58:56 +0200, Hans de Goede wrote: > Marcin Zaj?czkowski wrote: >> On 2007-05-28 9:51:18 +0200, Hans de Goede wrote: >> (...) >>> Either way I volunteer myself as co-maintainer for gnome-applet-sensors, >>> because of my involvednes in lmsensors upstream. >> >> Great! Even though we are still waiting for Aaron Kurtz reply I think >> that having comaintainer will be good for g-a-s anyway, especially that >> F7 (and updates for it) will be available for thousands of Fedora users >> very soon. >> In my opinion you could start procedure of comaintainer addition [1] and >> update a package (also for FC-5 and FC-6 branches). >> > > That would be more like a package take-over then co-maintainer ship. > I'll start working on gnome-applet-sensors as soon as the current > maintainer thinks this is a good idea and not a minute earlier. Ok, I'm not hurry. I have version 1.7.12 compiled by myself. Do you want to start AWOL procedure? http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers Regards Marcin From cra at WPI.EDU Wed May 30 22:16:57 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 30 May 2007 18:16:57 -0400 Subject: Web-only release notes deadline 30 May 23:59 UTC In-Reply-To: <1180464246.3439.1220.camel@erato.phig.org> References: <1180464246.3439.1220.camel@erato.phig.org> Message-ID: <20070530221657.GN31145@angus.ind.WPI.EDU> On Tue, May 29, 2007 at 11:44:06AM -0700, Karsten Wade wrote: > http://fedoraproject.org/wiki/Docs/Beats I see that the useless obsolete info is still there for Vaio users. There is no replacement advice that works with libata AFAIK, so it should just be removed: Installation Related Issues Sony VAIO Notebooks Some Sony VAIO notebook systems may experience problems installing Fedora from CD-ROM. If this happens, restart the installation process and add the following option to the boot command line: pci=off ide1=0x180,0x386 Installation should proceed normally, and any devices not detected are configured the first time Fedora is booted. From cra at WPI.EDU Wed May 30 22:23:12 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 30 May 2007 18:23:12 -0400 Subject: Web-only release notes deadline 30 May 23:59 UTC In-Reply-To: <20070530221657.GN31145@angus.ind.WPI.EDU> References: <1180464246.3439.1220.camel@erato.phig.org> <20070530221657.GN31145@angus.ind.WPI.EDU> Message-ID: <20070530222312.GO31145@angus.ind.WPI.EDU> On Wed, May 30, 2007 at 06:16:57PM -0400, Chuck Anderson wrote: > Sony VAIO Notebooks > > Some Sony VAIO notebook systems may experience problems installing > Fedora from CD-ROM. If this happens, restart the installation process > and add the following option to the boot command line: > > pci=off ide1=0x180,0x386 Bug filed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241831 From j.w.r.degoede at hhs.nl Wed May 30 23:05:23 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 31 May 2007 01:05:23 +0200 Subject: A new version of gnome-applet-sensors In-Reply-To: <465DE941.9070205@wp.pl> References: <46596B29.6010407@wp.pl> <1180266908.11117.6.camel@rousalka.dyndns.org> <4659AFB2.2070005@hhs.nl> <1180307592.3493.5.camel@rousalka.dyndns.org> <465A89F6.2000700@hhs.nl> <465C7294.4080700@wp.pl> <465C77F0.4090108@hhs.nl> <465DE941.9070205@wp.pl> Message-ID: <465E0333.90104@hhs.nl> Marcin Zaj?czkowski wrote: > On 2007-05-29 20:58:56 +0200, Hans de Goede wrote: >> Marcin Zaj?czkowski wrote: >>> On 2007-05-28 9:51:18 +0200, Hans de Goede wrote: >>> (...) >>>> Either way I volunteer myself as co-maintainer for gnome-applet-sensors, >>>> because of my involvednes in lmsensors upstream. >>> Great! Even though we are still waiting for Aaron Kurtz reply I think >>> that having comaintainer will be good for g-a-s anyway, especially that >>> F7 (and updates for it) will be available for thousands of Fedora users >>> very soon. >>> In my opinion you could start procedure of comaintainer addition [1] and >>> update a package (also for FC-5 and FC-6 branches). >>> >> That would be more like a package take-over then co-maintainer ship. >> I'll start working on gnome-applet-sensors as soon as the current >> maintainer thinks this is a good idea and not a minute earlier. > > Ok, I'm not hurry. I have version 1.7.12 compiled by myself. > > > Do you want to start AWOL procedure? > No, Feel free todo it your self, once its orphaned (if it gets that far) I'll see if I can find the time to pick it up. Regards, Hans From notting at redhat.com Thu May 31 00:00:22 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 30 May 2007 20:00:22 -0400 Subject: Pushing updates for Fedora 7 Message-ID: <20070531000022.GA10430@nostromo.devel.redhat.com> Bodhi is now available for update submission at: https://admin.fedoraproject.org/updates/ You'll need to log in with your FAS username/password. For more information on what bodhi is, and how to use it, see: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT Bill From lmacken at redhat.com Thu May 31 00:15:57 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 30 May 2007 20:15:57 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531000022.GA10430@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> Message-ID: <20070531001557.GA2650@tomservo.rochester.rr.com> On Wed, May 30, 2007 at 08:00:22PM -0400, Bill Nottingham wrote: > Bodhi is now available for update submission at: > https://admin.fedoraproject.org/updates/ > > You'll need to log in with your FAS username/password. > > For more information on what bodhi is, and how to use it, see: > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT Please note that bodhi may seem a bit sluggish as it is not fully tweaked for production yet (CherryPy is still serving static files, and there is alot of debugging output, etc). It's also running on code that I've been hacking on all day :) I apologize for the last-minute deployment, but we decided to rewrite the entire code that is responsible for pushing updates, and we're still polishing it up. You should be able to submit updates without a problem. I'm hoping within a couple of days you will be able to do everything from the command-line as well as via the web interface. luke From caillon at redhat.com Thu May 31 02:16:31 2007 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 30 May 2007 22:16:31 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531000022.GA10430@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> Message-ID: <465E2FFF.1020605@redhat.com> Bill Nottingham wrote: > Bodhi is now available for update submission at: > https://admin.fedoraproject.org/updates/ How would one include multiple packages in an update, as per the current (RH-internal) update tool? Or is this not yet implemented? From lmacken at redhat.com Thu May 31 03:08:37 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 30 May 2007 23:08:37 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <465E2FFF.1020605@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <465E2FFF.1020605@redhat.com> Message-ID: <20070531030837.GB2650@tomservo.rochester.rr.com> On Wed, May 30, 2007 at 10:16:31PM -0400, Christopher Aillon wrote: > Bill Nottingham wrote: > > Bodhi is now available for update submission at: > > https://admin.fedoraproject.org/updates/ > > How would one include multiple packages in an update, as per the current > (RH-internal) update tool? Or is this not yet implemented? Not yet implemented. Multi-package update support in the current tool is essentially a hack. We'll need to do this correctly this time around (if we even want to support multi-package updates). luke From jkeating at redhat.com Thu May 31 03:14:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 May 2007 23:14:51 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531030837.GB2650@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <465E2FFF.1020605@redhat.com> <20070531030837.GB2650@tomservo.rochester.rr.com> Message-ID: <200705302314.51718.jkeating@redhat.com> On Wednesday 30 May 2007 23:08:37 Luke Macken wrote: > Not yet implemented. ?Multi-package update support in the current tool > is essentially a hack. ?We'll need to do this correctly this time around > (if we even want to support multi-package updates). EEEEk! how can we help you get this going? Will be quite necessary. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bos at serpentine.com Thu May 31 04:56:32 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 30 May 2007 21:56:32 -0700 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531030837.GB2650@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <465E2FFF.1020605@redhat.com> <20070531030837.GB2650@tomservo.rochester.rr.com> Message-ID: <465E5580.7030200@serpentine.com> Luke Macken wrote: > We'll need to do this correctly this time around (if > we even want to support multi-package updates). This is definitely important. There are plenty of collections of packages where updating one requires that a bunch of others be updated simultaneously, or all hell breaks loose. Witness the OCaml stuff recently discussed, and the existing Haskell packages. References: <20070531000022.GA10430@nostromo.devel.redhat.com> <465E2FFF.1020605@redhat.com> <20070531030837.GB2650@tomservo.rochester.rr.com> <465E5580.7030200@serpentine.com> Message-ID: <465E56A6.6020809@ioa.s.u-tokyo.ac.jp> Bryan O'Sullivan wrote, at 05/31/2007 01:56 PM +9:00: > Luke Macken wrote: > >> We'll need to do this correctly this time around (if >> we even want to support multi-package updates). > > This is definitely important. There are plenty of collections of > packages where updating one requires that a bunch of others be updated > simultaneously, or all hell breaks loose. Witness the OCaml stuff > recently discussed, and the existing Haskell packages. Also important for gecko-dependent packages update. Mamoru From cweyl at alumni.drew.edu Thu May 31 05:03:42 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 30 May 2007 22:03:42 -0700 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531001557.GA2650@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070531001557.GA2650@tomservo.rochester.rr.com> Message-ID: <7dd7ab490705302203k578930dbx34644a883e03d0e3@mail.gmail.com> On 5/30/07, Luke Macken wrote: > You should be able to submit updates without a problem. I'm hoping > within a couple of days you will be able to do everything from the > command-line as well as via the web interface. Is there a published API to access that's somewhat stable? :) -Chris -- Chris Weyl Ex astris, scientia From lmacken at redhat.com Thu May 31 06:29:20 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 31 May 2007 02:29:20 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <7dd7ab490705302203k578930dbx34644a883e03d0e3@mail.gmail.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070531001557.GA2650@tomservo.rochester.rr.com> <7dd7ab490705302203k578930dbx34644a883e03d0e3@mail.gmail.com> Message-ID: <20070531062920.GC2650@tomservo.rochester.rr.com> On Wed, May 30, 2007 at 10:03:42PM -0700, Chris Weyl wrote: > On 5/30/07, Luke Macken wrote: > > You should be able to submit updates without a problem. I'm hoping > > within a couple of days you will be able to do everything from the > > command-line as well as via the web interface. > > Is there a published API to access that's somewhat stable? :) It doesn't exist yet, but it will shortly :) luke From lmacken at redhat.com Thu May 31 06:37:06 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 31 May 2007 02:37:06 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <200705302314.51718.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <465E2FFF.1020605@redhat.com> <20070531030837.GB2650@tomservo.rochester.rr.com> <200705302314.51718.jkeating@redhat.com> Message-ID: <20070531063706.GD2650@tomservo.rochester.rr.com> On Wed, May 30, 2007 at 11:14:51PM -0400, Jesse Keating wrote: > On Wednesday 30 May 2007 23:08:37 Luke Macken wrote: > > Not yet implemented. ?Multi-package update support in the current tool > > is essentially a hack. ?We'll need to do this correctly this time around > > (if we even want to support multi-package updates). > > EEEEk! how can we help you get this going? Will be quite necessary. Well, based on the way things are designed now, there cannot be a single update containing multiple packages. So a simple solution to this problem is to make it trivial to submit and run requests on multiple updates at once. The web form could be altered to allow any number of builds, which would then create an individual update for each one with the same bugs/cves/notes. We could then throw checkboxes next to each update in the list and allow people to request pushes of multiple updates at once. Doing this from a command-line tool would be even easier. (eg, `bodhi submit ..`). What do you guys think? Would this be sufficient? luke From sheltren at cs.ucsb.edu Thu May 31 11:40:26 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 31 May 2007 07:40:26 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531000022.GA10430@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> Message-ID: <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> On May 30, 2007, at 8:00 PM, Bill Nottingham wrote: > Bodhi is now available for update submission at: > https://admin.fedoraproject.org/updates/ > > You'll need to log in with your FAS username/password. > > For more information on what bodhi is, and how to use it, see: > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi- > info-DRAFT > > Bill > Luke, thanks for all your work on Bodhi! Does anyone have an answer to the question at the bottom of the Bodhi wiki page: - Are we going to have any rule for how long things should be in updates-testing? How much QA? How many good/bad? Was this already discussed somewhere? :) Also, it looks like I can revoke/edit push requests. Is that intended behavior? Jesse, I clicked on the revoke link for your pungi package and it seemed to successfully revoke the push request. I clicked the link to push it again, so it should be back to normal (awaiting push), but please verify! -Jeff From jkeating at redhat.com Thu May 31 12:31:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 31 May 2007 08:31:30 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> Message-ID: <200705310831.31097.jkeating@redhat.com> On Thursday 31 May 2007 07:40:26 Jeff Sheltren wrote: > Also, it looks like I can revoke/edit push requests. ?Is that ? > intended behavior? ?Jesse, I clicked on the revoke link for your ? > pungi package and it seemed to successfully revoke the push request. ? > I clicked the link to push it again, so it should be back to normal ? > (awaiting push), but please verify! We haven't hooked in a good ACL method yet. still working on that (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Thu May 31 13:16:50 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 31 May 2007 09:16:50 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531063706.GD2650@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <465E2FFF.1020605@redhat.com> <20070531030837.GB2650@tomservo.rochester.rr.com> <200705302314.51718.jkeating@redhat.com> <20070531063706.GD2650@tomservo.rochester.rr.com> Message-ID: <1180617410.9051.3.camel@aglarond.local> On Thu, 2007-05-31 at 02:37 -0400, Luke Macken wrote: > On Wed, May 30, 2007 at 11:14:51PM -0400, Jesse Keating wrote: > > On Wednesday 30 May 2007 23:08:37 Luke Macken wrote: > > > Not yet implemented. Multi-package update support in the current tool > > > is essentially a hack. We'll need to do this correctly this time around > > > (if we even want to support multi-package updates). > > > > EEEEk! how can we help you get this going? Will be quite necessary. > > Well, based on the way things are designed now, there cannot be a > single update containing multiple packages. So a simple solution to > this problem is to make it trivial to submit and run requests on multiple > updates at once. > > The web form could be altered to allow any number of builds, which would > then create an individual update for each one with the same bugs/cves/notes. > We could then throw checkboxes next to each update in the list and allow people > to request pushes of multiple updates at once. Doing this from a command-line > tool would be even easier. (eg, `bodhi submit ..`). > > What do you guys think? Would this be sufficient? You really want the update to have multiple (source) packages associated with it, though -- think about the case where I have a highly interdependent set of packages that are released together upstream, etc. I want to have just one update mail sent listing all of the packages and then also see them grouped together as a set within pup. Otherwise, the fact that multiple packages can use the same updateinfo really doesn't help much and we could have just kept doing srpm-level grouping :-/ Jeremy From bnocera at redhat.com Thu May 31 14:58:31 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 31 May 2007 15:58:31 +0100 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531000022.GA10430@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> Message-ID: <1180623511.3030.178.camel@cookie.hadess.net> Hey Bill, On Wed, 2007-05-30 at 20:00 -0400, Bill Nottingham wrote: > Bodhi is now available for update submission at: > https://admin.fedoraproject.org/updates/ > > You'll need to log in with your FAS username/password. > > For more information on what bodhi is, and how to use it, see: > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT The FAQ mentions that new packages need to go through Bodhi (question 3 and 6), but the form doesn't allow to select "new package" in the type drop-down. Is it an enhancement, or a bugfix, or neither? Cheers From caillon at redhat.com Thu May 31 15:11:57 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 May 2007 11:11:57 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <200705310831.31097.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <551430FF-1AB0-4A5E-8335-50CD886D51A9@cs.ucsb.edu> <200705310831.31097.jkeating@redhat.com> Message-ID: <465EE5BD.5040708@redhat.com> Jesse Keating wrote: > On Thursday 31 May 2007 07:40:26 Jeff Sheltren wrote: >> Also, it looks like I can revoke/edit push requests. Is that >> intended behavior? Jesse, I clicked on the revoke link for your >> pungi package and it seemed to successfully revoke the push request. >> I clicked the link to push it again, so it should be back to normal >> (awaiting push), but please verify! > > We haven't hooked in a good ACL method yet. still working on that (: Although I beg, not yet. Please fix https://hosted.fedoraproject.org/projects/bodhi/ticket/31 first. It was the only workaround I could viably use for submitting my update request. From jkeating at redhat.com Thu May 31 15:11:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 31 May 2007 11:11:46 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <1180623511.3030.178.camel@cookie.hadess.net> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> Message-ID: <200705311111.46953.jkeating@redhat.com> On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: > Is it an enhancement, or a bugfix, or neither? Enhancement (to the distribution) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Thu May 31 16:03:14 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 31 May 2007 12:03:14 -0400 Subject: Upcoming FESCo Election Message-ID: <1180627394.5867.2.camel@lincoln> Hi All! It's that time of year again. Everyone that wants to be in the next FESCo needs to nominate him/herself for it by June 12, 2007 0:00 UTC; that self-nomination should contain some information's like "Mission Statement, Past work summary and Future plans". Please place your nomination on this page in the wiki: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations The actual election will start on Thursday, June 14, 2007 0:01 UTC and will last until Sunday, June 24, 2007 23:59 UTC. The results will be posted to the fedora-devel list. The first meeting of the "new" FESCo will be on Thursday, July 05, 2007 on #fedora-meeting at 17:00 UTC. A new chair will be elected there by the new members. For more information regarding the election, please refer to this: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cweyl at alumni.drew.edu Thu May 31 16:09:08 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 31 May 2007 09:09:08 -0700 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531062920.GC2650@tomservo.rochester.rr.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <20070531001557.GA2650@tomservo.rochester.rr.com> <7dd7ab490705302203k578930dbx34644a883e03d0e3@mail.gmail.com> <20070531062920.GC2650@tomservo.rochester.rr.com> Message-ID: <7dd7ab490705310909s287216f2j41836ea17ad91bda@mail.gmail.com> On 5/30/07, Luke Macken wrote: > On Wed, May 30, 2007 at 10:03:42PM -0700, Chris Weyl wrote: > > On 5/30/07, Luke Macken wrote: > > > You should be able to submit updates without a problem. I'm hoping > > > within a couple of days you will be able to do everything from the > > > command-line as well as via the web interface. > > > > Is there a published API to access that's somewhat stable? :) > > It doesn't exist yet, but it will shortly :) Awesome. I await anxiously :) -Chris (Note I'm being really liberal with "published". So long as I can decipher it from source even, I'm good.) -- Chris Weyl Ex astris, scientia From limb at jcomserv.net Thu May 31 17:43:52 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 31 May 2007 12:43:52 -0500 (CDT) Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531000022.GA10430@nostromo.devel.redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> Message-ID: <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> This may have been answered elsewhere and I missed it, but do we have to do bodhi updates for packages with updates built before GA that are tagged dist-fc7-updates-candidate, or will these be pushed automagically? > Bodhi is now available for update submission at: > https://admin.fedoraproject.org/updates/ > > You'll need to log in with your FAS username/password. > > For more information on what bodhi is, and how to use it, see: > http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT > > Bill > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From jkeating at redhat.com Thu May 31 17:55:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 31 May 2007 13:55:51 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> Message-ID: <200705311355.51477.jkeating@redhat.com> On Thursday 31 May 2007 13:43:52 Jon Ciesla wrote: > This may have been answered elsewhere and I missed it, but do we have to > do bodhi updates for packages with updates built before GA that are tagged > dist-fc7-updates-candidate, or will these be pushed automagically? You have to push updates for them, they will not be pushed automatically. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu May 31 17:56:28 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 31 May 2007 13:56:28 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> Message-ID: <20070531175628.GB21110@nostromo.devel.redhat.com> Jon Ciesla (limb at jcomserv.net) said: > This may have been answered elsewhere and I missed it, but do we have to > do bodhi updates for packages with updates built before GA that are tagged > dist-fc7-updates-candidate, or will these be pushed automagically? They will not be pushed automatically. Bill From limb at jcomserv.net Thu May 31 17:59:17 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 31 May 2007 12:59:17 -0500 (CDT) Subject: Pushing updates for Fedora 7 In-Reply-To: <200705311355.51477.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> <200705311355.51477.jkeating@redhat.com> Message-ID: <40965.65.192.24.190.1180634357.squirrel@mail.jcomserv.net> Good to know, I'll get on that. Thanks. > On Thursday 31 May 2007 13:43:52 Jon Ciesla wrote: >> This may have been answered elsewhere and I missed it, but do we have to >> do bodhi updates for packages with updates built before GA that are >> tagged >> dist-fc7-updates-candidate, or will these be pushed automagically? > > You have to push updates for them, they will not be pushed automatically. > > -- > Jesse Keating > Release Engineer: Fedora > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- novus ordo absurdum From mtasaka at ioa.s.u-tokyo.ac.jp Thu May 31 19:03:40 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 01 Jun 2007 04:03:40 +0900 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> Message-ID: <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> updates at fedoraproject.org wrote, at 06/01/2007 03:08 AM +9:00: > -------------------------------------------------------------------------------- > Fedora Update Notification > FEDORA-2007-0001 > None > -------------------------------------------------------------------------------- > > Name : firefox > Product : Fedora 7 > Version : 2.0.0.4 > Release : 1.fc7 > Summary : Mozilla Firefox Web browser. > Description : > Mozilla Firefox is an open-source web browser, designed for standards > compliance, performance and portability. Well, actually this updates should be pushed with some other packages depending on gecko engine in firefox? Otherwise this will cause dependency break or some package won't be working _silently_ after firefox update. Mamoru From bugs.michael at gmx.net Thu May 31 19:19:23 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Thu, 31 May 2007 21:19:23 +0200 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> Message-ID: <20070531211923.5aca60d5.bugs.michael@gmx.net> On Fri, 01 Jun 2007 04:03:40 +0900, Mamoru Tasaka wrote: > > Fedora Update Notification > > FEDORA-2007-0001 > > None > > -------------------------------------------------------------------------------- > > > > Name : firefox > > Product : Fedora 7 > > Version : 2.0.0.4 > > Release : 1.fc7 > > Summary : Mozilla Firefox Web browser. > > Description : > > Mozilla Firefox is an open-source web browser, designed for standards > > compliance, performance and portability. > > Well, actually this updates should be pushed with some > other packages depending on gecko engine in firefox? > Otherwise this will cause dependency break or some package > won't be working _silently_ after firefox update. And: Too late for FC-6. Many broken deps reports have been triggered. From jspaleta at gmail.com Thu May 31 19:18:15 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 31 May 2007 11:18:15 -0800 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> Message-ID: <604aa7910705311218k501e1b26rc3315f7753da6613@mail.gmail.com> On 5/31/07, Mamoru Tasaka wrote: > Well, actually this updates should be pushed with some > other packages depending on gecko engine in firefox? > Otherwise this will cause dependency break or some package > won't be working _silently_ after firefox update. Check updates-testing to see if any affected gecko using packages are in the pipeline as updates already. Start filing bugs against the packages which use the gecko engine and ask for updates. Since this is a critical security update, you'll be hard pressed to make a persuasive argument that in this case it was worth waiting for the other packages to build. Security can trump functionality. -jef"xulrunner where are you?!?"spaleta From caillon at redhat.com Thu May 31 19:33:00 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 May 2007 15:33:00 -0400 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> Message-ID: <465F22EC.8060400@redhat.com> Mamoru Tasaka wrote: > updates at fedoraproject.org wrote, at 06/01/2007 03:08 AM +9:00: >> -------------------------------------------------------------------------------- >> >> Fedora Update Notification >> FEDORA-2007-0001 >> None >> -------------------------------------------------------------------------------- >> >> >> Name : firefox >> Product : Fedora 7 >> Version : 2.0.0.4 >> Release : 1.fc7 >> Summary : Mozilla Firefox Web browser. >> Description : >> Mozilla Firefox is an open-source web browser, designed for standards >> compliance, performance and portability. > > Well, actually this updates should be pushed with some > other packages depending on gecko engine in firefox? Otherwise this will > cause dependency break or some package > won't be working _silently_ after firefox update. I did push out updates for some packages that I knew about. But our update system for F-7 doesn't support multiple package updates. See the bodhi thread for more. From jkeating at redhat.com Thu May 31 20:07:59 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 31 May 2007 16:07:59 -0400 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <20070531211923.5aca60d5.bugs.michael@gmx.net> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> <20070531211923.5aca60d5.bugs.michael@gmx.net> Message-ID: <200705311608.00024.jkeating@redhat.com> On Thursday 31 May 2007 15:19:23 Michael Schwendt wrote: > Too late for FC-6. Many broken deps reports have been triggered. Due to FC6 and FE6 being in different buildsystems still, I made sure the Core repo was closed before pushing. Something that should get better as we bring core/extras into the same build system for 6 too, once we iron out the wrinkles in 7. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Thu May 31 20:14:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 31 May 2007 16:14:37 -0400 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> Message-ID: <200705311614.37509.jkeating@redhat.com> On Thursday 31 May 2007 15:03:40 Mamoru Tasaka wrote: > Well, actually this updates should be pushed with some > other packages depending on gecko engine in firefox? > Otherwise this will cause dependency break or some package > won't be working _silently_ after firefox update. This is somewhat my fault. I thought that the push would die if there were broken deps, or at least warn me so that I could decide on pushing or not. That isn't quite hooked up yet, so the push just went out. We'll be working on better repo closure stuff soon, although it's a bit fun with multilib involved :/ -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jbowes at redhat.com Thu May 31 21:56:17 2007 From: jbowes at redhat.com (James Bowes) Date: Thu, 31 May 2007 17:56:17 -0400 Subject: Pushing updates for Fedora 7 In-Reply-To: <200705311355.51477.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> <200705311355.51477.jkeating@redhat.com> Message-ID: <20070531175617.2dab7ad8@localhost.localdomain> On Thu, 31 May 2007 13:55:51 -0400, Jesse Keating wrote: > On Thursday 31 May 2007 13:43:52 Jon Ciesla wrote: > > This may have been answered elsewhere and I missed it, but do we have to > > do bodhi updates for packages with updates built before GA that are tagged > > dist-fc7-updates-candidate, or will these be pushed automagically? > > You have to push updates for them, they will not be pushed automatically. > Would it be feasible (or useful?) to generate reports for packages that have been build for F-whatever X days ago, but have not been submitted to bodhi? -James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Thu May 31 22:49:43 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 01 Jun 2007 00:49:43 +0200 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <465F22EC.8060400@redhat.com> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> <465F22EC.8060400@redhat.com> Message-ID: <465F5107.4020504@poolshark.org> Christopher Aillon wrote: > Mamoru Tasaka wrote: >> updates at fedoraproject.org wrote, at 06/01/2007 03:08 AM +9:00: >>> -------------------------------------------------------------------------------- >>> >>> Fedora Update Notification >>> FEDORA-2007-0001 >>> None >>> -------------------------------------------------------------------------------- >>> >>> >>> Name : firefox >>> Product : Fedora 7 >>> Version : 2.0.0.4 >>> Release : 1.fc7 >>> Summary : Mozilla Firefox Web browser. >>> Description : >>> Mozilla Firefox is an open-source web browser, designed for standards >>> compliance, performance and portability. >> >> Well, actually this updates should be pushed with some >> other packages depending on gecko engine in firefox? Otherwise this >> will cause dependency break or some package >> won't be working _silently_ after firefox update. > > I did push out updates for some packages that I knew about. But our > update system for F-7 doesn't support multiple package updates. See the > bodhi thread for more. I'm having trouble with rebuilding galeon for F-7: looks as though firefox-devel is not present even though the BR should bring it in. http://koji.fedoraproject.org/koji/getfile?taskID=22104&name=build.log I noticed the firefox RPMs on update-testing are not signed, could this be the reason ? From jspaleta at gmail.com Thu May 31 22:53:03 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 31 May 2007 14:53:03 -0800 Subject: Pushing updates for Fedora 7 In-Reply-To: <20070531175617.2dab7ad8@localhost.localdomain> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <39512.65.192.24.190.1180633432.squirrel@mail.jcomserv.net> <200705311355.51477.jkeating@redhat.com> <20070531175617.2dab7ad8@localhost.localdomain> Message-ID: <604aa7910705311553x52c17cbbp37f609912cff0001@mail.gmail.com> On 5/31/07, James Bowes wrote: > Would it be feasible (or useful?) to generate reports for packages that > have been build for F-whatever X days ago, but have not been submitted > to bodhi? I think we may want to attempt to watch this, at least for the transitional period as people start learning that they need to use bodhi for packages to actually go out. -jef From bugs.michael at gmx.net Thu May 31 23:05:11 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 1 Jun 2007 01:05:11 +0200 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <465F5107.4020504@poolshark.org> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> <465F22EC.8060400@redhat.com> <465F5107.4020504@poolshark.org> Message-ID: <20070601010511.d065ebaa.bugs.michael@gmx.net> On Fri, 01 Jun 2007 00:49:43 +0200, Denis Leroy wrote: > I'm having trouble with rebuilding galeon for F-7: looks as though > firefox-devel is not present even though the BR should bring it in. > > http://koji.fedoraproject.org/koji/getfile?taskID=22104&name=build.log > > I noticed the firefox RPMs on update-testing are not signed, could this > be the reason ? http://koji.fedoraproject.org/koji/getfile?taskID=22104&name=root.log Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/dist-fc7-build-6559-1136/root resolvedep 'gecko-devel = 1.8.1.4' 'perl(XML::Parser)' 'libgnomeui-devel >= 2.5.2' 'scrollkeeper' 'gettext' 'gtk2-devel >= 2.4.0' 'intltool' 'gnome-desktop-devel' 'desktop-file-utils' 0:firefox-devel-2.0.0.4-0.rc3.fc7.i386 0:perl-XML-Parser-2.34-6.1.2.2.1.i386 0:libgnomeui-devel-2.18.1-2.fc7.i386 0:scrollkeeper-0.3.14-11.fc7.i386 0:gettext-0.16.1-8.fc7.i386 0:gtk2-devel-2.10.11-7.fc7.i386 0:intltool-0.35.5-3.fc7.i386 0:gnome-desktop-devel-2.18.0-4.fc7.i386 0:desktop-file-utils-0.12-4.fc7.i386 ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: desktop-file-utils i386 0.12-4.fc7 core 51 k firefox-debuginfo i386 2.0.0.4-0.rc3.fc7 core 60 M ^^^^^^^^^ Here's one problem! Resolver was asked for gecko-devel, returned firefox-devel, but installed was firefox-debuginfo instead. From caillon at redhat.com Thu May 31 23:20:01 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 May 2007 19:20:01 -0400 Subject: [SECURITY] Fedora 7 Update: firefox-2.0.0.4-1.fc7 In-Reply-To: <20070601010511.d065ebaa.bugs.michael@gmx.net> References: <200705311808.l4VI8Lpo003174@bastion.fedora.phx.redhat.com> <465F1C0C.40203@ioa.s.u-tokyo.ac.jp> <465F22EC.8060400@redhat.com> <465F5107.4020504@poolshark.org> <20070601010511.d065ebaa.bugs.michael@gmx.net> Message-ID: <465F5821.4060107@redhat.com> Michael Schwendt wrote: > Here's one problem! > Resolver was asked for gecko-devel, returned firefox-devel, but installed > was firefox-debuginfo instead. That should be fixed in the -1 package which just got released, but broken in the rc3 package. Just re-submit, and it'll likely iron itself out. From bnocera at redhat.com Thu May 31 23:48:08 2007 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 01 Jun 2007 00:48:08 +0100 Subject: Pushing updates for Fedora 7 In-Reply-To: <200705311111.46953.jkeating@redhat.com> References: <20070531000022.GA10430@nostromo.devel.redhat.com> <1180623511.3030.178.camel@cookie.hadess.net> <200705311111.46953.jkeating@redhat.com> Message-ID: <1180655288.25009.12.camel@cookie.hadess.net> On Thu, 2007-05-31 at 11:11 -0400, Jesse Keating wrote: > On Thursday 31 May 2007 10:58:31 Bastien Nocera wrote: > > Is it an enhancement, or a bugfix, or neither? > > Enhancement (to the distribution) It would be easier if the update was a bit clever about new packages, and made them bypass updates-testing automatically.